OpenStreetMap

Users' diaries

Recent diary entries

ToDo

Posted by revi^ on 31 July 2015 in English (English)
  • Change Korean (English) style nodes to use proper properties (not sure if this is correct term)
  • Change zipcode (5 digits since 2015-08-01)

Diferença entre (tentar) arrumar algo fora do OSM

Posted by naoliv on 30 July 2015 in Brazilian Portuguese (Português do Brasil)

Um amigo me dizendo que alteraram o sentido da rua que ele mora no Waze:

Ah, o waze, ia te falar. Mexeram lá, não pode mais virar na minha rua. Aí reclamei... um usuário editor respondeu. Cadastrei no site que edita mas não tenho privilégio ainda. Eu respondi pro cara meu argumento e ele ignorou. Vou ver se entro lá depois no chat pra discutir com alguém que tenha poder

E depois:

Pior que por causa disso o waze tá gerando umas rotas zoadas. E até menos de 1 mês atrás tava OK

Ao contrário do exemplo acima, no OSM qualquer um pode editar qualquer lugar, sem burocracia e com o diferencial de dar importância às pessoas que têm conhecimento do local!

private bookmarks on new lane marking for complex layouts and junctions

Posted by Govanus on 30 July 2015 in English (English)

Access=no

Posted by JakubMap on 30 July 2015 in Polish (Polski)

Skoncentrowanie się na zakazach ruchu i drogach jednokierunkowych. Ewentualne poprawki statusu dróg. Trzebini, Chrzanów, Płaza, Babice, Zator, Wadowice ... kierunek Zakopane drogą 28, potem 47.

Mapping turn lanes in OpensStreetMap

Posted by andygol on 30 July 2015 in English (English)

Hi, folks!

I want to share with you my blog post about mapping turn lanes

If you have any suggestions, you can write it here in comments


Mapping turn lanes in OpensStreetMap

Complex intersections often involve lane-specific turn restrictions. See for instance these overhead signs on Utah State Route 92, crossing Interstate 15 just south of Salt Lake City.

turn lanes sign

Lane signage on Utah State Route 92. Photo: Garrett.

We need turn restrictions for every individual lane to provide precise directions for drivers. In OpenStreetMap we model turn lane information with two tagging schemes:

Here is a guide on how to map turn lanes with OpenStreetMap's JOSM editor. Note that type=turnlanes:turns is a proposed feature. You can join the proposal process by submitting your review on the relevant talk page.

Mapping Turn Lanes

First, install the turn lane plugin directly from JOSM's settings panel. It provides support for both Key:turn tags and type=turnlanes:turns relations.

As an example, let's look at how to map turn lanes in detail on this intersection alongside US 101 in South San Francisco.

image

Lane-specific turn restrictions along US 101 Exit 425B.

Enable the "Turn Lanes" panel in the "Windows" menu.

josm_open_turnlanes_dialog

Identify the number of lanes on all the roads leading to and from the junction.

image

Add the number of lanes to the appropriate ways as a regular tag - for example, lanes=2.

image

Split the ways that will be parts of relations. Then, for each turn lane restriction, select the nodes and ways involved to define a rule. You should see the junction modeled as shown once the lane count for all the roads have been set.

josm_open_turnlanes_construct_junction

Let's start with the motorway link from US 101 leading into the junction.

exit_to=Oyster Point Boulevard; highway=motorway_junction; ref=425B

Initially this way has one lane which splits into three before the junction. At 141 meters before the junction, add the left lane. At 92 meters, add the lane on the right side. These lanes can be added by clicking the white plus button and setting the start position by dragging the blue marker back from the junction.

josm_open_turnlanes_add_side_lanes

Add a lane to turn left for a small section of Dubuque Avenue. You can pan the model by dragging with the right mouse button.

josm_open_turnlanes_add_side_lane

Now create rules for the thoroughfare from motorway junction #425B with rules for each lane by dragging a route across the relevant junctions and lanes.

josm_open_turnlanes_add_turn_ruls

Add similar rules for all directions where applicable.

Now let's check our work by selecting nodes and reviewing traffic flow. To cycle through all directions press Ctrl+A for an overview of all restrictions on the junction.

josm_open_turnlanes_check_in_out

I hope you find these instructions useful to map detailed junctions in your area. If you have any questions or ideas on mapping turn lanes, drop me a line on Twitter or through my OpenStreetMap profile.

Header photo: Interstate 10 and Interstate 17 Interchange at Night by Alan Stark

Location: Veterans Blvd, South San Francisco, San Mateo County, California, 94080, United States of America

# Mapeando México con INEGI, contigo y...Cygnus

Posted by Mapanauta on 29 July 2015 in Spanish (Español)

Publicado por mvexel el 29 julio 2015 Traducido al Español por @Mapanauta

México liberó una gran cantidad de datos abiertos hace poco tiempo. Huge: Mexico's statistical institute INEGI goes open data @INEGI_INFORMA (via @rodowi — Alex Barth (@lxbarth)

Mucha de esta información es geoespacial, por eso digo ¡yummie! Alex Barth escribió acerca de estos datos que vienen del Instituto Nacional de Geografía y Estadística (INEGI) en su diario poco tiempo después de la liberación con un excelente mapa para mostrar que tan rica es la información:

(Mis habilidades mediocres para animaciones GIF realmente no le hacen justicia – chequen la publicación del Blog de Alex para ver el mapa interactivo).

Ahora la pregunta es: ¿Cómo obtenemos una parte (o todo?) de estos datos en OSM? Esto no está claro –OSM ya cuenta con datos valiosos en muchos lugares en México que definitivamente queremos mantener. Aquí en el equipo OSM de Telenav obtuvimos la respuesta a esta pregunta. Le llamamos Cygnus - El portador del Equilibrio. Déjenme explicar con algunos visuales lo que hace Cygnus. Consideren esta área en la región de Aguascalientes. Existe actualmente información de OSM ahí:

Si vemos las imágenes aéreas de Bing, podemos ver que hay una población completa que ¡aún no ha sido mapeada!

Pero INEGI tiene la mayoría o si no todos las calles en esta población en su conjunto de datos ahora abierto llamado Conjunto de Datos Vectoriales de Carreteras y Vialidades Urbanas .

Después de convertir los atributos originales de los datos al etiquetado correcto de OSM, guardar los resultados a un archivo OSM y cargarlo en JOSM se ve de la siguiente forma:

OK, eso está bien pero aún tenemos dos diferentes capas que están desconectadas e incluso si se fusionan tenemos que resolver manualmente caminos duplicados y conecciones entre los caminos de OSM y aquellos provenientes de los datos de INEGI.

Aquí es donde Cygnus entra- desarrollamos en Telenav una nueva tecnología de fusión específicamente para afrontar esto.

Gygnus, como el Portador de Equilibrio, toma los que se ingresó como base en archivo OSM en formato PBF, así como lo que llamamos archivo 'mejorado', también en formato PBF. Después los compara y fusiona los dos ingresos (inputs) y da como resultado un archivo JOSM XML que puede ser fusionado con la base de datos OSM de manera inmediata. Estos detalles muestran las capas combinadas con todos los caminos 'importados' del INEGI antes de los caminos pre-existentes de OSM

Aunque Cygnus hace un trabajo impresionante de fusionar datos OSM con la capa ‘mejorada’, aún tienes que checar el resultado antes de hacer subir la información. Checa el ejemplo aquí:

La 'highway=secondary' ya estaba pre-existente a los datos OSM y la 'highway=residential' ; 'oneway=yes' vino de los datos de INEGI, está claro por las imágenes de Bing que hay dos caminos que deben estar conectados y todavía no lo están. Cygnus tiene un umbral de distancia (modificable) que utiliza cuando decide si dos caminos deben de estar conectados o no. En este caso, el camino de INEGI estaba muy lejos por ello permaneció desconectado.

Hay otras cosas por considerar cuando trabajas con archivos de cambio producidas por Cygnus:

  • Cygnus nunca va a degradar datos existentes de OSM
  • Cuando ambos OSM y la capa mejorada tienen el mismo camino, Cygnus va a mantener siempre la geometría original OSM pero opcionalmente va a importar 'name' y otras etiquetas útiles.

Estamos trabajando en un plan de importación para los datos del INEGI que harán uso intenso de esta tecnología ¡Más acerca de esto muy pronto! Mientras tanto checa nuestra charla en SOTM US con respecto a los datos de INEGI y OSM en México.

CanVec Import for 085F05 (Fort Providence NWT)

Posted by JamesBadger_CanVecImport on 29 July 2015 in English (English)

I am working on improving the data availability for some of the major northern Canadian arctic communities, as improving this data in OpenStreetMap will also improve the Arctic Web Map project that is using OSM data.

I have downloaded the shapefiles from NRCan and I used ogr2ogr to convert them from EPSG:4140 to EPSG:4326. Then I am importing them a layer at a time using JOSM. I am using the CanVec Feature Catalogue and OSM CanVec Feature Guide for mapping values.

For the vegetation layer "085f05_11_0_VE_1240019_2" (Wooded area classified — polygons) I imported the shapefile into QGIS and used a dissolve operation to combine all the polygons. Then a Douglas generalize filter with a tolerance of 0.0001 was applied to remove redundant vertices. This reduced the vertex count from 363,000 to 40,000. Next I opened that shapefile in JOSM and changed the tags to natural=wood and manually merged the polygons with identical polygons in the neighbouring imported tiles.

I will continue importing one layer at a time until this NTS tile is complete.

Location: Loop A, Northwest Territories, Canada

Mapeando México con INEGI, contigo y...Cygnus

Posted by Mapanauta on 29 July 2015 in Spanish (Español)

Publicado por mvexel el 29 julio 2015 Traducido al Español por Mapanauta

México liberó una gran cantidad de datos abiertos hace poco tiempo. Huge: Mexico's statistical institute INEGI goes open data @INEGI_INFORMA (via @rodowi — Alex Barth (@lxbarth)

Mucha de esta información es geoespacial, por eso digo ¡yummie! Alex Barth escribió acerca de estos datos que vienen del Instituto Nacional de Geografía y Estadística (INEGI) en su diario poco tiempo después de la liberación con un excelente mapa para mostrar que tan rica es la información:

(Mis habilidades mediocres para animaciones GIF realmente no le hacen justicia – chequen la publicación del Blog de Alex para ver el mapa interactivo).

Ahora la pregunta es: ¿Cómo obtenemos una parte (o todo?) de estos datos en OSM? Esto no está claro –OSM ya cuenta con datos valiosos en muchos lugares en México que definitivamente queremos mantener. Aquí en el equipo OSM de Telenav obtuvimos la respuesta a esta pregunta. Le llamamos Cygnus - El portador del Equilibrio. Déjenme explicar con algunos visuales lo que hace Cygnus. Consideren esta área en la región de Aguascalientes. Existe actualmente información de OSM ahí:

Si vemos las imágenes aéreas de Bing, podemos ver que hay una población completa que ¡aún no ha sido mapeada!

Pero INEGI tiene la mayoría o si no todos las calles en esta población en su conjunto de datos ahora abierto llamado Conjunto de Datos Vectoriales de Carreteras y Vialidades Urbanas .

Después de convertir los atributos originales de los datos al etiquetado correcto de OSM, guardar los resultados a un archivo OSM y cargarlo en JOSM se ve de la siguiente forma:

OK, eso está bien pero aún tenemos dos diferentes capas que están desconectadas e incluso si se fusionan tenemos que resolver manualmente caminos duplicados y conecciones entre los caminos de OSM y aquellos provenientes de los datos de INEGI.

Aquí es donde Cygnus entra- desarrollamos en Telenav una nueva tecnología de fusión específicamente para afrontar esto.

Gygnus, como el Portador de Equilibrio, toma los que se ingresó como base en archivo OSM en formato PBF, así como lo que llamamos archivo 'mejorado', también en formato PBF. Después los compara y fusiona los dos ingresos (inputs) y da como resultado un archivo JOSM XML que puede ser fusionado con la base de datos OSM de manera inmediata. Estos detalles muestran las capas combinadas con todos los caminos 'importados' del INEGI antes de los caminos pre-existentes de OSM

Aunque Cygnus hace un trabajo impresionante de fusionar datos OSM con la capa ‘mejorada’, aún tienes que checar el resultado antes de hacer subir la información. Checa el ejemplo aquí:

La 'highway=secondary' ya estaba pre-existente a los datos OSM y la 'highway=residential' ; 'oneway=yes' vino de los datos de INEGI, está claro por las imágenes de Bing que hay dos caminos que deben estar conectados y todavía no lo están. Cygnus tiene un umbral de distancia (modificable) que utiliza cuando decide si dos caminos deben de estar conectados o no. En este caso, el camino de INEGI estaba muy lejos por ello permaneció desconectado.

Hay otras cosas por considerar cuando trabajas con archivos de cambio producidas por Cygnus:

  • Cygnus nunca va a degradar datos existentes de OSM
  • Cuando ambos OSM y la capa mejorada tienen el mismo camino, Cygnus va a mantener siempre la geometría original OSM pero opcionalmente va a importar 'name' y otras etiquetas útiles.

Estamos trabajando en un plan de importación para los datos del INEGI que harán uso intenso de esta tecnología ¡Más acerca de esto muy pronto! Mientras tanto checa nuestra charla en SOTM US con respecto a los datos de INEGI y OSM en México.

Stammtische und Berlin im Detail

Posted by Christopher on 29 July 2015 in German (Deutsch)

Da mir am Wochenende danach nach war, tauchte ich etwas tiefer in die Geschichte des Berlin-Brandenburger Stammtisches ein. Anfangs fand er jeden 2. Donnerstag, heute abwechselnd jeden 2. Donnerstag bzw. 2. Freitag statt. Seit diesem Juni findet der Stammtisch zusammen mit dem FOSSGIS-Stammtisch statt, der zuvor in Potsdam seinen Sitz hatte. Da ich seit dem 2.Treffen regelmäßig dabei bin, der Meinung war, dass Berlin einer der ältesten sein müsste und wir bereits sehr viele Treffen hatten machte ich mich auf die Suche.Zum Glück waren bis auf das erste Treffen alle Treffen im Wiki geplant. Also öffnete ich mein LibreOffice und legte los, sind ja nur knapp rund 600 Versionen von der Wikiseite vorhanden. Der erste Stammtisch in Berlin fand am 10.07.2008 in der Pizzeria SI statt. Zunächst habe ich nur die verschiedenen Lokalitäten zusammen getragen, die ich dann auf der Wikiseite zum Stammtisch in den Abschnitt historisches eingetragen habe.

Lokalitäten

Folgende Restaurants und Lokalitäten dienten in den Jahren als Unterschlupf für den Stammtisch:

  • Restaurant/Pizzeria SI (Juli 2008)
  • Café auszeit (August 2008 - Februar 2009)
  • Tante Elli (März 2009 - Juli 2010)
  • c-base (August 2010 - Juli 2013)
  • Resonanz (August 2013 - heute)

Neben diesen Lokalitäten fanden 2 Treffen in den Jahren 2010 und 2011 im Romiosini am ICC statt, weil in der Woche vom Stammtisch auch der LinuxTag stattfand. Hier haben wir uns dann am Freitag zum Abendessen getroffen. Wie ich feststellen musste, fiel auch 2014 LinuxTag und Stammtisch in die gleiche Woche, auch hier war ein Abendessen geplant, aber es fand sich niemand für die Organisation. So war es seit Beginn des Stammtischs der Mai 2014 der einzige Monat an dem es kein Treffen gab. Auch in den anderen Jahren gab Freitagabends die Zusammenkünfte vom gemeinsamen FOSSGIS- und OSM-Stand. Diese flossen, da der Stammtisch auch regulär statt fand, nicht in die Statistik mit ein. Des Weiteren gab es nur im Mai 2010 eine Verlegung des Stammtisches um eine Woche. Der ursprüngliche Termin war ein Herrentag. Auch im Jahr 2015 fiel der Stammtisch auf einen Herrentag, dieser wurde aber nicht verschoben, es waren insgesamt 5 Teilnehmer vor Ort, bei 3 Anmeldungen im Wiki, somit genauso viel wie im Vormonat.

Zahlenspielerei

Anzahl der Treffen

Hier die Lokalitäten mit den Anzahl der Treffen sowie durchschnittliche Anmeldungen im Wiki.

  • Cafe auszeit - 7 Treffen - 6,29 Besucher
  • Tante Elli - 16 Treffen - 6,19 Besucher
  • c-base - 35 Treffen - 3,97 Besucher
  • Resonanz - 23 Treffen - 4,00 Besucher

Die maximale Zahl von Anmeldungen war am 13.08.2009 mit 11 Teilnehmer, danach haben sich nie wieder mehr als 9 Teilnehmer angemeldet.

Hierbei muss man sagen, dass die Wiki-Anmeldungen nicht die wirklichen Besucherzahlen widerspiegeln."Es gab einmal einen Abend mit 18 Stammtischbesuchern, an dem bis auf eine Person alle erstmals den Stammtisch besucht haben." - siehe Der Stammtisch im Wandel der Zeit

Anzahl der Besuche

Hier die Top 5 der Besucher (84 Stammtische):

  1. Peter (B10xyz) 43x
  2. Thorsten (Bluescreen) 41x
  3. Christopher 40x
  4. Marcus (Roald-linus) 31x
  5. Sasha (Toaster) 28x

Abgänge / Zugänge

Zudem wurde die durchschnittliche Zahl der neuen OSM-Nutzer (Zugang) sowie die Nutzer die letztmalig auf dem Stammtisch waren (Abgang) nach Standort zusammengefasst:

  • Cafe auszeit - 3,00 Zugang - 1,86 Abgang
  • Tante Elli - 1,38 Zugang - 1,13 Abgang
  • c-base - 0,57 Zugang - 0,57 Abgang
  • Resonanz - 0,48 Zugang - 0,74 Abgang

Da für den ersten Stammtisch keine Daten vorliegen, so ein paar Details zum 2. Stammtisch. Es waren 8 Teilnehmer angemeldet, 3 hiervon kamen nicht wieder bzw. haben sich nicht angemeldet.

Jubiläum

Da der Stammtisch im Mai 2014 nicht statt gefunden hat, wir der Stammtisch im November 2016 zum 100. mal statt finden. Ich denke das sollten wir irgendwie feiern.

Vergleich mit anderen Städten

Um Herauszufinden wie der Berlin-Brandenburger Stammtisch im Vergleich zu den anderen Stammtischen da steht habe ich mich auf allen Stammtischseiten im Wiki umgeschaut um herauszufinden ob diese noch aktiv sind und wie lange diese bereits existieren. Einige Städte haben seit dem ersten Stammtisch eine "Chronik" angelegt, dort war es ganz einfach den ersten Stammtisch herauszufinden. Bei anderen Stammtischen war das nicht so einfach und man musste auf der Stadtseite suchen in welcher Version der erste Eintrag zum Stammtisch vorgenommen wurde. Insgesamt wurden dabei 58 Stammtische in Deutschland betrachtet.

Hier die Liste der deutschen Stammtische, die sich noch regelmäßig treffen, das Datum zeigt das erste Treffen an:

  1. München 12.10.06
  2. Hamburg 09.10.07
  3. Dresden 03.01.08
  4. Hannover 18.05.08
  5. Karlsruhe 24.06.08
  6. Berlin 10.07.08
  7. Stuttgart 19.07.08
  8. Essen 11.08.08
  9. Dortmund 21.09.08
  10. Göttingen 30.09.08
  11. Lüneburg 21.10.08
  12. Braunschweig 02.12.08
  13. Rostock 19.01.09
  14. Lübeck 02.04.09
  15. Bonn 15.06.09
  16. Zittau 05.08.09
  17. Landshut 05.10.09
  18. Viersen 22.02.10
  19. Düsseldorf 31.03.10
  20. Augsburg 08.04.10
  21. Darmstadt 04.10.10
  22. Passau 03.02.11
  23. Ulm / Neu-Ulm 09.02.12
  24. Lüchow-Dannenberg 18.10.12
  25. Bremen 29.04.13
  26. Freiberg (Mittelsachsen) 17.10.13

Sollte sich ein aktiver Stammtisch hier nicht wieder finden bzw. das Jahr falsch zu sein, so werde ich das entsprechend korrigieren.

Ich hoffe wir sehen uns zur Nummer 85 am 14.08.2015 19:00 im Resonanz Berlin Stadtteil Schöneberg.

Christopher

Location: Schöneberg, Tempelhof-Schöneberg, Berlin, Deutschland

Mapping Mexico with INEGI, you and...Cygnus

Posted by mvexel on 29 July 2015 in English (English)

Mexico released a huge amount of open data not too long ago.

Huge: Mexico's statistical institute INEGI goes open data @INEGI_INFORMA (via @rodowi — Alex Barth (@lxbarth)

A lot of this data is geospatial, so I say yummie! Alex Barth wrote about this data, that comes from the Mexican national statistical agency INEGI, on his diary before, with a nifty map to show how rich this data is:

inegi-mapbox

(My mediocre animated GIF skills really don't do it justice - check out Alex's blog post to see an interactive map.)

So now the question becomes: how do we get some (or all?) of this data into OSM? This is not straightforward - OSM already has rich data in many places in Mexico we would definitely want to keep.

Here at the Telenav OSM team, we have come up with an answer to this question. We call it Cygnus - The Bringer of Balance. Let me explain in a few visuals what Cygnus does.

Consider this area in the Aguascalientes region. There is some OSM data there:

base osm

If we look at the Bing aerial images, we can clearly see that there's an entire village there that is not mapped though!

base osm with bing

But INEGI has most if not all the roads in this village in their now open dataset Conjunto de Datos Vectoriales de Carreteras y Vialidades Urbanas.

After converting the original data attributes mapped to OSM-appropriate tagging, saving the result as an OSM file, and loading it into JOSM, it looks like this:

cygnus-osm-cvu

OK, that is nice, but we still have two separate layers that are unconnected, and even if we merge them, we will still have to manually resolve duplicate ways and connections between the ways from OSM and those from the INEGI data.

This is where Cygnus comes in - a new conflation technology we developed at Telenav specifically to tackle this.

Cygnus, as the Bringer of Balance, takes as its input a base OSM file in PBF format, as well as what we call an 'enhancing' file, also in PBF format. It will then compare and conflate the two inputs and output one JOSM XML file that can be merged with OSM base data straight away. This detail shows the merged layers with all the INEGI 'imported' ways connected to the pre-existing OSM way:

cygnus merged

Even though Cygnus does a pretty amazing job merging OSM data with an 'enhancing' layer, you will still need to check the result before you upload. Take this example here:

cygnus miss

The highway=secondary was the pre-existing OSM data, and the highway=residential; oneway=yes came from INEGI data. It is clear from Bing imagery that the two ways should be connected, yet they are not. Cygnus has a (tweakable) distance threshold it uses when it decides if two ways should be connected or not. In this case, the INEGI way was too far away, so it remained disconnected.

There are a few other things to consider when you work with a Cygnus-produced change file:

  • Cygnus will never degrade existing OSM data
  • When both OSM and the enhancing layer have the same way, Cygnus will always keep the original OSM geometry, but it will optionally import name and other useful tags.

We are currently working on an import plan for INEGI data that will make heavy use of this new technology. More about this very soon! In the mean time, watch our SOTM US talk on the INEGI data and OSM in Mexico.

Restoring measurements from crashed database of Tower Collector

Posted by Kolesár on 29 July 2015 in English (English)

I'm an OpenCellID contributor. I use Tower Collector application on Android phones for recording cell data. I have recorded data for more than 500,000 locations.

One day one of my phones has shut down on a trip after 80 kilometers which I will never do again. I have checked Locus where the tracklog stopped: a few kilometers behind. Started Tower Collector, it showed zero locations! Oh my god. I had another trip previous day which was not uploaded yet.

This device was rooted, started root browser, checked the application's data directory:

    /data/data/info.zamojski.soft.towercollector

In directory "databases" I have seen an empty measurements.db (a few kB), but there was another file: measurements.db.back with 600 kB! Made a backup copy of the whole directory and resumed my route.

At home I have checked the db. It is an sqlite database, but has been corrupted.

    sqlite> pragma integrity_check;
    Error: database disk image is malformed

I have made a dump of the database:

    echo .dump | sqlite3 measurements.db.back > measurements.sql

There were 2059 measurements for 76 cells, valuable data. How to restore them? Load back to Tower Collector. I did not have time for that for weeks, but continued collecting new data. I was frustrated because this phone did not remember the cells collected before the crash, displayed a most of cells as new. I have also missed the data from that two trips. Some weeks later I have tried to load data.

At first I have created a new database using the recovered data but I have failed many times. I replaced measurements.db with the new one, app crashed (SQLiteCantOpenDatabaseException). Checked directory and file permissions via Root Browser, it showed root as owner of every file, but later I have checked the same thing via adb and it showed totally different owners: every app has a userid and owner should be set correctly.

After setting owner for the database, I had another kind of crash: Tower Collector said "upgrading database" and crashed again. Stack trace had an SQL statement: "CREATE TABLE cells" which failed because cells table already existed. Why does it upgrade? I did not see any difference in schema of old and current database.

Then I started a different way. Prepared only data from the dump: kept only INSERT statements for the following tables:

    INSERT INTO "measurements" ...
    INSERT INTO "cells_archive" ...
    INSERT INTO "cells" ...

Uploaded this file via adb:

    adb push inserts.sql /data/data/info.zamojski.soft.towercollector/databases/inserts.sql

Then restored the last working measurements.db and logged in via adb:

    $ adb shell
    ~ # cd /data/data/info.zamojski.soft.towercollector/databases
    # sqlite3 measurements.db

Here I had an almost empty database, only cells_archive table had 1227 rows. I have truncated this to make history clean:

    # DELETE FROM cells_archive;

Then I imported the SQL file just uploaded:

    # .read inserts.sql

Logged out and tested: app displayed 2059 measurements for 76 cells. Quickly uploaded to OpenCellID and checked newly uploaded measurements there.

Then I merged the new cells captured since the failure. Dumped cells_archive from the previously backed up version of measurements.db, replaced table name "cells_archive" to "cells", loaded into the database using the same way and then deleted them. This database has a trigger which archives rows deleted from table "cells" to "cells_archive" ignoring duplicates.

I had seen 6176 cells before the crash. Since then there were 1227 new, merging resulted 6793 cells, 617 new. The rest were duplicates.

The last step was setting total number of locations to the sum measurements before and after crash:

UPDATE stats SET total_locations = 156440+29641 WHERE row_id=1;

Now I have a database which knows all cells and number of locations since I have started collecting data. I am happy.

Location: Ürögi út, Nagyberény, Siófoki kistérség, Somogy megye, Southern Transdanubia, Transdanubia, 8656, Hungary

Jaskyňa vo Vraženej

Posted by Mirecnet on 29 July 2015 in Slovak (Slovenčina)

Skuska dennika

Location: Kráľovská Ľubeľa, Ľubeľa, okres Liptovský Mikuláš, Žilinský kraj, Stredné Slovensko, Slovensko

Extracting regions from planet.osm ?

Posted by adaviel on 28 July 2015 in English (English)

I've been using Merkaartor on LInux for some years. Usually I import a track, zoom in, then use "download more" to download OSM for that region. But there's a 50,000 item limit, so if I'm not zoomed in far enough, it fails.

Years ago I had read that I could get planet.osm as a default start set, but I never did. Now, when I look, it's huge. Merkaartor can't handle that, at least not with the amount of RAM I have. It can't even handle all of Canada without swapping.

I see that the US is split into states, but all of Canada is one big file. Is there any easy way, preferably command-line on Linux, that would let me split out a region from the Canada OSM - one province, or a smaller area ?

Improving the OSM map - why don't we? [7]

Posted by marczoutendijk on 28 July 2015 in English (English)

How do we deal with multiple values for a key?

We all know this situation: you need to add a telephone number to a node and add the line:
phone=00311198765432
Then you find out that there is a second phone number for that node, but you can't add a second phone= tag because OSM doesn't allow that.
The general question is: how do I tag multiple values for one key?
Let's investigate how mappers have solved that problem sofar. The screenshots all are made with OpenPoiMap.


[1.]
This example is the Eiffel tower in Paris for which four architects worked together, but only one gave his name to the final product!
In the source the names are separated with semicolons:
Stephen Sauvestre;Gustave Eiffel;Maurice Koechlin;Émile Nouguier


[2.] One piece of art created by 5 artists (somewhere in Seattle).
Create a new key with a sequential number attached to it for every member of this group. In this specific case I would have started numbering with artist_number_2 because the first one is already in artist_name. Even better, I would have started with artist_name_1 and used it for Andrew Keating and would have omitted artist_name altogether.


[3.] This example is to show how to map multiple sets of related tags to one node. In this case we have man_made=mast which has attached to it 4 (mobile phone) antennas at different heigth and each working with a different technology.
An underscore could have been used as in the previous example, but there seems to be a tendency to tag situations like this with a key:N notation, where N is running over the natural numbers.


[4.] Here we see a combination of both methods. Adding a number (with underscore) at the end of the key to count them or adding the number after the colon. Again, in the case of the fuel I would have started with fuel:diesel:1 for the Biosolar.

Any different opinions on this subject?

All GPS-tracks in an area?

Posted by geoeki on 28 July 2015 in English (English)

Hi there,

is there somehow a possibility to visualize all GPS-tracks that were gethered for the same area? For example I use JOSM, I define my area of interest and for that specific AoI I want to fetch all available GPS-tracks. Hope that was clear!

Thanks!

Location: Alservorstadt, Alsergrund, Vienna, 1090, Austria

witam wszystkich

Posted by hedstrom on 28 July 2015 in Polish (Polski)

witam wszystkich

Vendiendo casas de lujo por todo el mundo

Posted by Rodrigao on 28 July 2015 in Spanish (Español)

Me dedico a la venta de casas de lujo y a partir de ahora donde haga una venta lo pondré en el mapa.

Removing phone booths in Belgium

Posted by M!dgard on 28 July 2015 in English (English)

All Belgacom/Proximus telephone booths in Belgium are removed from the streets. With changeset #32926155 those that had operator=Belgacom or Proximus have also been removed from OSM.

The remaining phone booths before their removal. Most of them are near Brussels.

I used the following Overpass query:

/* Find all Belgacom/Proximus phone booths in bbox */
(
  node[amenity=telephone][operator~"[Bb]elgacom|[Pp]roximus"]({{bbox}});
  <;
  >;
);

out meta qt;

This fetched all phone booths and also any ways they are connected to. No relations were matched, which was good. Then, in JOSM, I did the following searches to obtain phone booths that are member of a way:

  • type:way (no phone booths were tagged as ways)
  • amenity=telephone child selected

I removed all tags on those 4 nodes.

Then I searched all remaining amenity=telephones and removed the nodes.

Some stats:

  • There were 320 Belgacom/Proximus phone booths left in OSM in Belgium.
  • 316 had operator=Belgacom, 2 belgacom and 2 Belgacom NV
  • 3 phone booths had covered=yes, 1 had covered=no.

Note that at the time of writing there are still 320 other amenity=telephones left in Belgium. (Exactely the same number as I removed!) They haven't been tagged with operator=Belgacom and should be manually surveyed and removed if necessary.

You are invited to add a note like verified that this phone still exists 2015-07-28 to any phones that you have surveyed, to prevent mappers from armchair-mapping them away. (They shouldn't, but just to be sure.) An operator tag is appreciated as well.

Search for amenity=telephones in Belgium

/* Find all phone booths in Belgium */
area["name:en"="Belgium"]->.belgium;
(
  node(area.belgium)[amenity=telephone];
);

out qt;

Jazda z satelity (geoportal, wspomaganie bing).

Posted by JakubMap on 28 July 2015 in Polish (Polski)

Wrzucam z satelity co się da, weryfikując status dróg pod renderowanie dla Yanosika. Teren Trzebinia i Młoszowa. W razie wątpliwości weryfikacja w terenie. Główne cele: 1) Tagi ograniczenia ruchu. 2) Jakość drogi - które drogi nie nadają się do jazdy autem o słabszym zawieszeniu.

Treinando aos 60

Posted by Rogério Paulo on 27 July 2015 in Portuguese (Português)

Pois é; Eu que passei uma vida, com excepção dos tempos de escuteiros, dos 9 aos 19 anos de idade, a não praticar nenhum desporto, vejo-me agora ao completar os 60 anos de idade, entusiasmado com a prática desportiva. - Não é para bater recordes, ou atingir metas, apenas para manutenção e manter o corpo em forma, porque os músculos já começavam a ficar flácidos. Desportos: Ciclismo, corrida e caminhadas.

Older Entries | Newer Entries