Re: [Talk-de] overpass turbo - eine Web-GUI für die Overpass-API

[christian.pietz...@googlemail.com]

Danke Martin
hat funktioniert.

Ich habe es jetz in JOSM importiert, dort dann als GPX gespeichert und zu
Locus importiert. Bis auf den Fakt, dass er beim Importieren dann nochmal
für jeden Punkt einen Track angelegt hat (vermutlich meine Schuld), hat es
super geklappt.
Ich habe schon lange versucht, alle Boofen in der sächsischen Schweiz als
POIs zu bekommen und hatte mich vor kurzem per Hand ran gemacht. Mit
OverpassTurbo liefs aber viel besser und schneller.

Danke für das tolle Tool
Freue mich bereits auf weitere Verbesserungen

mfg Christian


Am 28. Januar 2013 19:38 schrieb Martin Raifer :

> Hallo Christian
>
>  Ich habe heute versucht ein paar Daten in JOSM zu exportiren. [...]
>>
>> Was habe ich falsch gemacht. In JOSM ist remote control aktiviert
>>
>
> Du musst statt  folgendes verwenden:
>
> 
>
> Ohne das mode="meta" kann JOSM mit den Daten nichts anfangen. Ich glaube
> ich werde demnächst für die "load into JOSM" Funktion noch eine Warnung
> einbauen, wenn man das mode="meta" vergessen hat.
>
> Liebe Grüße
> Martin
>
>
> __**_
> Talk-de mailing list
> Talk-de@openstreetmap.org
> http://lists.openstreetmap.**org/listinfo/talk-de
>
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] JOSM - Konflikt auflösen

[Markus]

Hallo Michael,


meinst Du diesen hier?


Ja - herzlichen Dank für Deine schnelle Hilfe :-)
Markus


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] JOSM - Konflikt auflösen

[Michael Bemmerl]

Hi,

meinst Du diesen hier?

https://josm.openstreetmap.de/browser/josm/trunk/src/org/openstreetmap/josm/gui/dialogs/ConflictResolutionDialog.java

Grüße,
Michael

Markus schrieb:
> Liebe Entwickler,
> 
> wo finde ich den Code für das Fenster,
> mit dem Konflikte beim Hochladen von Daten gelöst werden können?
> 
> Danke, Markus
> 
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de




signature.asc
Description: OpenPGP digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

[Talk-de] JOSM - Konflikt auflösen

[Markus]

Liebe Entwickler,

wo finde ich den Code für das Fenster,
mit dem Konflikte beim Hochladen von Daten gelöst werden können?

Danke, Markus

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Nominatim: Postgresql Kernel Panic Out of Memory durch Import

[Sarah Hoffmann]

On Tue, Jan 29, 2013 at 10:02:58AM +0100, jotpe wrote:
> Hallo zusammen.
> 
> Ich versuche germany.tar.bz2 (2GB) in OSM zu importieren. Jedoch wurde bei
> den letzen zwei Importen ein Kernel Panic "Out of Memory" ausgelöst.
> 
> Die Maschine hat 5 GB RAM, Debian Squeeze mit Postgressql 9.2.2. Mit den
> Standardeinstellungen des Pgsql konnte der Regierungsbezirk Köln (100MB)
> erfolgreich indiziert werden.
> 
> Dann habe ich nach dem Vorbild "Tuning PGSQL" in
> http://wiki.openstreetmap.org/wiki/Nominatim/Installation die Memory-Werte
> in postgresql.conf erhöht, damit ich nicht solange warten muss. Dort habe
> ich die Werte nach Gefühl von den beschriebenen 32GB auf meine 5GB
> angepasst.
> 
> Als der erste Versuch germany bereits Stunden lief, wollte ich "nebenbei"
> das OSRM kompilieren und währrenddesen war der Server plötzlich nicht mehr
> erreichbar. Im Serverraum sah ich dann die Meldung Kernel Panic: Out of
> Memory, konnte keine Prozesse mehr töten...
> 
> Vor dem zweiten Versuch stellt ich fest, dass durch einen
> Rechtschreibfehler gar kein swap (5 GB) aktiviert war => mit swapon
> nachgeholt. Ich verringerte die Speicherwerte (aber wegen jetzt verfügbaren
> Swap nur wenig) und ließ von weiteren parallelem Kompilieren ab.
> 
> shared_buffers = 950 MB ( 1GB mit echo "1073741824" >
> /proc/sys/kernel/shmmax )
> maintance_work_mem = 3500 MB (war das zu hoch?, in der pgsql doku steht
> 256MB)

Das würde ich auf max. 1GB zurücksetzen.

> work_mem = ??  (konnte noch nicht nachsehen, kein Zugang Serverraum)
> effective_cache_size = ?? (dito)
> checkpoint_segments = 100
> checkpoint_timeout = 10min
> checkpoint_completion_target = 0.9
> 
> Wiederum trat vermutlich der gleiche Kernel Panic (mom. kein Zugang
> Serverraum) innerhalb des setup.php-Abschnittes "Loading word list", wo
> 49000 Datensätze in die Tabelle "word_frequencies" importiert werden.

Das klingt, als wenn du auf diesen bekannten Bug gestossen bist:
https://github.com/twain47/Nominatim/issues/31

Versuche mal den dort beschriebenen Workaround und lasse den Import
mit --disable-token-precalc laufen. 

> Fragen:
> 
>- Wenn ich die Standardeinstellungen der postgresql.conf
>wiederherstelle, kann ich dann einen Kernel Panic verhindern auf Kosten der
>Laufzeit, oder sind die voreingestellten Werte zu wenig für die großen
>Datenmengen, was wiederum zu einem Kernel Panic führt?

Bei obrigen Bug scheint Postgres seine Speicherlimite zu überschreiten,
insofern gibt es da keine Garantie.

>- Kann man vorher irgendwie prüfen, ob das mit dem Ram passt oder stellt
>sich das immer erst nach 10h Laufzeit heraus?

Leider kann man das nicht wirklich vorher prüfen.

>- Sagen wir pgsql bekommt maximal 3.5GB RAM dann bleiben noch 1.5GB
>übrig bevor der SWAP benutzt wird. D.h. ich muss darauf achten, dass noch
>genung RAM für das setup.php-Skript und osm2pgsql übrig bleiben. Wieviel %
>sind da sinnvoll?

Es ist etwas komplizierter als eine einfache Prozentzahl, weil vieles von dem
Speicher, den du in der config einstellst, dynamisch alloziiert wird und 
natürlich
auch osm2pgsql seine Speichergrösse dynamisch anpasst. In deienm Fall würde ich
postgres nicht mehr als 3GB RAM zugestehen, lieber weniger. Aber das ist jetzt
wirklich nur geschätzt. 

Sarah

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Nominatim: Postgresql Kernel Panic Out of Memory durch Import

[Peter Wendorff]

Am 29.01.2013 10:02, schrieb jotpe:

Hallo zusammen.

Ich versuche germany.tar.bz2 (2GB) in OSM zu importieren. Jedoch wurde bei
den letzen zwei Importen ein Kernel Panic "Out of Memory" ausgelöst.

Die Maschine hat 5 GB RAM, Debian Squeeze mit Postgressql 9.2.2. Mit den
Standardeinstellungen des Pgsql konnte der Regierungsbezirk Köln (100MB)
erfolgreich indiziert werden.

Dann habe ich nach dem Vorbild "Tuning PGSQL" in
http://wiki.openstreetmap.org/wiki/Nominatim/Installation die Memory-Werte
in postgresql.conf erhöht, damit ich nicht solange warten muss. Dort habe
ich die Werte nach Gefühl von den beschriebenen 32GB auf meine 5GB
angepasst.

Nun ja...
Du hast insgesamt 5 GB.
Du erlaubst Postgresql, 5GB zu benutzen
Der Kernel beschwert sich.
Warum?

Ehrlich gesagt wundert mich das soweit nicht ;)
Du solltest für das Betriebssystem und was auch immer sonst noch auf 
deiner Kiste läuft während des imports, auch noch den dafür nötigen 
Speicher freihalten. Ich würd mal auf 4GB oder so runtergehen.

Als der erste Versuch germany bereits Stunden lief, wollte ich "nebenbei"
das OSRM kompilieren und währrenddesen war der Server plötzlich nicht mehr
erreichbar. Im Serverraum sah ich dann die Meldung Kernel Panic: Out of
Memory, konnte keine Prozesse mehr töten...

dito.

Gruß
Peter

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Frage: Zu Adressvergabe

[Martin Koppenhoefer]

Am 29. Januar 2013 11:49 schrieb Falk Zscheile :
> Nein, wir erfassen Hausnummern. Und die setzt die Gemeinde fest. Das
> ergibt sich mittelbar aus § 126 Abs. 3 Satz 1 BauGB[1].


was da steht deutet eher auf Grundstücksnummern denn auf Hausnummern,
aber das wird, wie ja auch im BauGB erwähnt, landesrechtlich genauer
festgelegt.

Ansonsten +1

Gruß Martin

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Frage: Zu Adressvergabe

[Falk Zscheile]

Am 29. Januar 2013 10:53 schrieb Ronnie Soak :
>>
>> +0.5, ich habe auch kein Problem damit, Adressen mehrfach anzugeben,
>> aber im vorliegenden Fall ist es doch so, dass die Adresse für Museum
>> und Restaurant die Postanschrift ist (Verwaltung) und nicht die
>> Adresse des POI. In so einem Fall würde ich die "echte" Adresse
>> angeben, also wo sich der POI befindet. Sonst würde man ja in anderen
>> Fällen, wo die Postanschrift noch deutlich weiter von der eigentlichen
>> Anschrift entfernt ist, total seltsame Adress-Daten eintragen.
>>
>> Solche Eigenschaften wie "Postanschrift" erfassen wir - zumindest
>> bisher meines Wissens nach - überhaupt nicht in OSM, und ein solcher
>> Vorschlag würde sicherlich auch viele Kritiker auf den Plan rufen, mit
>> dem Hinweis, das seien keine Geobasisdaten.
>>
>
> Meines Wissens nach erfassen wir (hier ein sehr großes *leider* einfügen)
> gerade doch die Postanschrift. Und zwar die der Deutschen Post AG. Ich kann
> gerade schlecht im Wiki suchen, aber dass ist dort sogar irgendwo definiert.
> Das ist meines Wissens nach ein Erbe der Briten, für die die Adresse der
> Royal Mail der einzige vernünftige Standard war.
>
> Ich lass mich da gerne noch mal belehren, aber so ist mein Wissensstand.

Nein, wir erfassen Hausnummern. Und die setzt die Gemeinde fest. Das
ergibt sich mittelbar aus § 126 Abs. 3 Satz 1 BauGB[1].

Davon abweichende Postadresse, wie beispielsweise Postfächer oder
Postleitzahlen, die nur ein Unternehmen führt, mappen wir nicht.

Vorliegend haben wir einen Grenzfall: Das eigentliche Geschäft findet
sich im Anwesen Nr. 15, aber die Postanschrift des Geschäfts ist Nr.
14. Beides sind real existierende Objekte auf der Erdoberfläche und
damit Geodaten. Wenn wir uns sklavisch an unsere "on the groung rule"
halten, dann müsste das Objekt eigentlich die Nr. 15 bekommen, weil es
dort tatsächlich liegt und ich auch dort hin geroutet werden will (und
nicht zur Postadresse). Andererseits komme ich auch zum Ziel, wenn ich
mich zu "Geschäft in Nr. 14" routen lasse, obwohl ich bei Nr. 15
herauskomme, weil der entsprechende POI eben ins Polygon der Nr. 15
gemalt wurde.

Kurzum in der Theorie fragwürdig, in der Praxis durchaus tauglich.

Gruß, Falk

[1] http://www.gesetze-im-internet.de/bbaug/__126.html

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Frage: Zu Adressvergabe

[Martin Koppenhoefer]

Am 29. Januar 2013 10:53 schrieb Ronnie Soak :
> Meines Wissens nach erfassen wir (hier ein sehr großes *leider* einfügen)
> gerade doch die Postanschrift. Und zwar die der Deutschen Post AG. Ich kann
> gerade schlecht im Wiki suchen, aber dass ist dort sogar irgendwo definiert.
> Das ist meines Wissens nach ein Erbe der Briten, für die die Adresse der
> Royal Mail der einzige vernünftige Standard war.


habe dafür im Wiki keine Anhaltspunkte gefunden (lasse mich aber auch
gerne eines Besseren belehren), im Gegenteil steht hier:
http://wiki.openstreetmap.org/wiki/Proposed_features/House_numbers/Karlsruhe_Schema#Tags
dass die Adressdaten zur Geolokalisierung genutzt werden sollen
(können), woraus m.E. folgt, dass es die "echte" Adresse sein sollte,
und nicht der ggf. davon abweichende "legale" Firmensitz oder die
Postanschrift.

Gruß Martin

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Frage: Zu Adressvergabe

[Ronnie Soak]

>
> +0.5, ich habe auch kein Problem damit, Adressen mehrfach anzugeben,
> aber im vorliegenden Fall ist es doch so, dass die Adresse für Museum
> und Restaurant die Postanschrift ist (Verwaltung) und nicht die
> Adresse des POI. In so einem Fall würde ich die "echte" Adresse
> angeben, also wo sich der POI befindet. Sonst würde man ja in anderen
> Fällen, wo die Postanschrift noch deutlich weiter von der eigentlichen
> Anschrift entfernt ist, total seltsame Adress-Daten eintragen.
>
> Solche Eigenschaften wie "Postanschrift" erfassen wir - zumindest
> bisher meines Wissens nach - überhaupt nicht in OSM, und ein solcher
> Vorschlag würde sicherlich auch viele Kritiker auf den Plan rufen, mit
> dem Hinweis, das seien keine Geobasisdaten.
>

Meines Wissens nach erfassen wir (hier ein sehr großes *leider* einfügen)
gerade doch die Postanschrift. Und zwar die der Deutschen Post AG. Ich kann
gerade schlecht im Wiki suchen, aber dass ist dort sogar irgendwo definiert.
Das ist meines Wissens nach ein Erbe der Briten, für die die Adresse der
Royal Mail der einzige vernünftige Standard war.

Ich lass mich da gerne noch mal belehren, aber so ist mein Wissensstand.
Für POIs hat das durchaus Sinn, da es 'Kontaktdaten' sind. Für die
Routinginformation müsste man korrekterweise immer erst über die “is in“
Beziehung die Adresse des Gebäudes herausfinden, in dem sich die POI
befindet.

Gruss,
Chaos
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Frage: Zu Adressvergabe

[Martin Koppenhoefer]

Am 29. Januar 2013 08:48 schrieb Ronnie Soak :
>>
>> > Die Lösung bisher.
>> > Das Museum, das Restaurant und die Verwaltung bekommen jewals die gleiche
>> > Adresse. Problem, Adresse existiert mehrmals.
>> >
>> > Ist das problematisch?
>> >
>>
>
> Finde ich in Ordnung so.


+0.5, ich habe auch kein Problem damit, Adressen mehrfach anzugeben,
aber im vorliegenden Fall ist es doch so, dass die Adresse für Museum
und Restaurant die Postanschrift ist (Verwaltung) und nicht die
Adresse des POI. In so einem Fall würde ich die "echte" Adresse
angeben, also wo sich der POI befindet. Sonst würde man ja in anderen
Fällen, wo die Postanschrift noch deutlich weiter von der eigentlichen
Anschrift entfernt ist, total seltsame Adress-Daten eintragen.

Solche Eigenschaften wie "Postanschrift" erfassen wir - zumindest
bisher meines Wissens nach - überhaupt nicht in OSM, und ein solcher
Vorschlag würde sicherlich auch viele Kritiker auf den Plan rufen, mit
dem Hinweis, das seien keine Geobasisdaten.


> Selbst wenn die POIs alle innerhalb des Gebaeudepolygons liegen, taggen
> viele die Adressdaten zusaetzlich an die POIs.
> Man erhofft sich wohl eine einfacherer Verabeitung durch externe Tools, da
> diese nicht erst nach der Adresse des umschliessenden building=* schauen
> muessen.


+1, eigentlich redundant aber nicht "schlimm"


> In deinem Fall passt die Adresse des building=* ja nun gerade nicht zum
> POI, die Daten MUESSEN also noch mal explizit irgendwo angegeben werden.
> An der POI ist da wohl die einfachste Loesung.


wie gesagt, eins ist die Adresse, das andere die Postanschrift. Wir
"müssen" die Postanschrift überhaupt nicht angegeben (m.E.). Wenn man
es kompliziert machen wollte könnte man an der Hausnummer 14 die
Verwaltung taggen und die dann per Relation mit dem Museum verbinden.

Gruß Martin

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

[Talk-de] Nominatim: Postgresql Kernel Panic Out of Memory durch Import

[jotpe]

Hallo zusammen.

Ich versuche germany.tar.bz2 (2GB) in OSM zu importieren. Jedoch wurde bei
den letzen zwei Importen ein Kernel Panic "Out of Memory" ausgelöst.

Die Maschine hat 5 GB RAM, Debian Squeeze mit Postgressql 9.2.2. Mit den
Standardeinstellungen des Pgsql konnte der Regierungsbezirk Köln (100MB)
erfolgreich indiziert werden.

Dann habe ich nach dem Vorbild "Tuning PGSQL" in
http://wiki.openstreetmap.org/wiki/Nominatim/Installation die Memory-Werte
in postgresql.conf erhöht, damit ich nicht solange warten muss. Dort habe
ich die Werte nach Gefühl von den beschriebenen 32GB auf meine 5GB
angepasst.

Als der erste Versuch germany bereits Stunden lief, wollte ich "nebenbei"
das OSRM kompilieren und währrenddesen war der Server plötzlich nicht mehr
erreichbar. Im Serverraum sah ich dann die Meldung Kernel Panic: Out of
Memory, konnte keine Prozesse mehr töten...

Vor dem zweiten Versuch stellt ich fest, dass durch einen
Rechtschreibfehler gar kein swap (5 GB) aktiviert war => mit swapon
nachgeholt. Ich verringerte die Speicherwerte (aber wegen jetzt verfügbaren
Swap nur wenig) und ließ von weiteren parallelem Kompilieren ab.

shared_buffers = 950 MB ( 1GB mit echo "1073741824" >
/proc/sys/kernel/shmmax )
maintance_work_mem = 3500 MB (war das zu hoch?, in der pgsql doku steht
256MB)
work_mem = ??  (konnte noch nicht nachsehen, kein Zugang Serverraum)
effective_cache_size = ?? (dito)
checkpoint_segments = 100
checkpoint_timeout = 10min
checkpoint_completion_target = 0.9

Wiederum trat vermutlich der gleiche Kernel Panic (mom. kein Zugang
Serverraum) innerhalb des setup.php-Abschnittes "Loading word list", wo
49000 Datensätze in die Tabelle "word_frequencies" importiert werden.


Fragen:

   - Wenn ich die Standardeinstellungen der postgresql.conf
   wiederherstelle, kann ich dann einen Kernel Panic verhindern auf Kosten der
   Laufzeit, oder sind die voreingestellten Werte zu wenig für die großen
   Datenmengen, was wiederum zu einem Kernel Panic führt?
   - Kann man vorher irgendwie prüfen, ob das mit dem Ram passt oder stellt
   sich das immer erst nach 10h Laufzeit heraus?
   - Sagen wir pgsql bekommt maximal 3.5GB RAM dann bleiben noch 1.5GB
   übrig bevor der SWAP benutzt wird. D.h. ich muss darauf achten, dass noch
   genung RAM für das setup.php-Skript und osm2pgsql übrig bleiben. Wieviel %
   sind da sinnvoll?


Vielen Dank für eure Hilfe.
Beste Grüße jotpe
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Frage: Zu Adressvergabe

[Ronnie Soak]

Ganz meine Meinung. Nur eine Bitte: in solch einem Fall ist es eine
> gute Idee in einer note den Hinweis zu hinterlassen, dass die Adressen
> tatsächlich abweichen. Es kommt sonst schon mal vor, dass jemand den
> vermeintlichen Fehler "ausbessert".
> Selbiges mache ich zum Beispiel auch, wenn ich einen Straßenverlauf
> aktualisiere, welcher auf den Luftbildern so noch nicht/nicht mehr zu
> sehen ist.
>

+1

Gruss,
Chaos
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Frage: Zu Adressvergabe

[Martin Vonwald]

Am 29. Januar 2013 08:48 schrieb Ronnie Soak :
>> > Die Lösung bisher.
>> > Das Museum, das Restaurant und die Verwaltung bekommen jewals die gleiche
>> > Adresse. Problem, Adresse existiert mehrmals.
>> > Ist das problematisch?
> Finde ich in Ordnung so. Es haben so wohl in der Realitaet mehrere
> 'Einheiten'  die selbe Adresse als
> auch in unserer Datenbank schon viele POIs die selben Adressdaten.
>
> Selbst wenn die POIs alle innerhalb des Gebaeudepolygons liegen, taggen
> viele die Adressdaten zusaetzlich an die POIs.
> Man erhofft sich wohl eine einfacherer Verabeitung durch externe Tools, da
> diese nicht erst nach der Adresse des umschliessenden building=* schauen
> muessen.
> In deinem Fall passt die Adresse des building=* ja nun gerade nicht zum
> POI, die Daten MUESSEN also noch mal explizit irgendwo angegeben werden.
> An der POI ist da wohl die einfachste Loesung.

Ganz meine Meinung. Nur eine Bitte: in solch einem Fall ist es eine
gute Idee in einer note den Hinweis zu hinterlassen, dass die Adressen
tatsächlich abweichen. Es kommt sonst schon mal vor, dass jemand den
vermeintlichen Fehler "ausbessert".
Selbiges mache ich zum Beispiel auch, wenn ich einen Straßenverlauf
aktualisiere, welcher auf den Luftbildern so noch nicht/nicht mehr zu
sehen ist.

vg,
Martin

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de