from:"Sarah Hoffmann"

Hi,

On Tue, Nov 05, 2013 at 02:36:20PM +0100, Florian Lohoff wrote:
Kreisfreie Städte sind in Deutschland leider irgendwo zwischen
level 6 und 8.
http://wiki.openstreetmap.org/wiki/File:Administrative_Gliederung_Deutschlands_admin_level.png
http://wiki.openstreetmap.org/wiki/DE:Tag:boundary%3Dadministrative

Schon klar - Eigentlich sind sie beides denn Administrativ uebernehmen
Kreisfreie Städte sowohl die Administrativen Tätigkeiten der Kreise wie
auch der Kommunen. Deshalb wäre ja der Ansatz das die Boundary sowohl
level 6 wie auch level 8 ist.

Leider ist es aber so zur Zeit nicht gemappt. Zur Zeit haben wir
nur boundaries mit admin_level=6 in der Datenbank und es gibt
praktisch keine Möglichkeit zwischen echten Kreisen und kreisfreien
Städten zu unterscheiden.

Ich kann verstehen wenn Nominatim mangels einer weiteren relation
level=8 (city) nur den level=6 (county) zurückgibt. Die gleiche
Relation nochmal in den city Wert zurückzugeben finde ich macht
wenig Sinn. Oder geht es darum, dass beim geocoden das Feld 'city'
nie leer sein sollte?

Genau - Sonst faengt jeder an die nominatim resultate mit code
aufzupimpen um das Ergebniss bewerten zu koennen.

Ich täte Nominatim diesbezüglich gerne verbessern, aber was es
dafür ersteinmal braucht, ist ein einheitliches Taggingschema
für das Problem boundary erstreckt sich über mehrere admin_levels.
Ich bin entschieden gegen soetwas wie 'de:place' weil das Problem
allgemein genug ist, dass es keine Sonderregelung für Deutschland
braucht.

Falls also jemand mal Lust hat, dass ganze auf tagging@ zur Sprache
zu bringen und es da dann eine Einigung gibt, könnte man das auch
irgendwie Nominatim beibringen.

Ich versuche gerade herauszufinden in wieweit man den nominatim
Ergebnissen trauen kann - D.h. wie bewerte ich ob die vollstaendige
und richtige Adresse gefunden wurde.

Die importance die zurueckgeliefert wird ist so weit ich das sehe
eher unbrauchbar. Bei vollstaendigen Adressen wie oben schwankt die
zwischen 0.600 und 1.1 - Und ob eine Hausnummer und vor allem
die abgefragt Hausnummer wirklich gefunden wurde sieht man da nicht.

Importance macht nur wirklich Sinn bei Objekten für die es einen
Wikipedia-Eintrag gibt, also eher oberhalb vom Strassen-Level.

Wenn du wissen willst, ob die Hausnummer gefunden wurde oder nur
die Strasse, empfehle ich place_rank zu parsen. Hausnummern haben
Rank 30, Strassen Rank 26 oder 27. Eine vollständige Liste der
Ranks ist hier:
http://wiki.openstreetmap.org/wiki/Nominatim/Development_overview#Indexing.2Faddress_calculation

Gruss

Sarah

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

Re: [Talk-de] nominatim und Kreisfreie Städte

On Tue, Nov 05, 2013 at 04:13:33PM +0100, Florian Lohoff wrote:
 Wo finde ich den denn?!? Ich finde noch ein type und class. Die sind 
 type=house
 class=place bei gefundenen Adressen sehe ich gerade. Das reicht mir so weit
 weil ich eh nur mit exakt gefundenen Adressen was anfangen kann.
 
 $ wget -O - -q 
 'http://nominatim.openstreetmap.org/?q=Dachsweg+2%2C+53125+Bonnformat=jsonaddressdetails=1'
  | perl -e 'use JSON; use Data::Dumper; print Dumper(decode_json(STDIN));'

Versuche es mal mit format=jsonv2.

Ich könnte schwören, es stand mal in der Doku, dass es verschiedene
json-Formate gibt. Habe es jetzt wieder angefügt. Der Hauptunterschied
zwischen beiden Formaten ist dass class in jsonv2 durch category 
ersetzt wurde.

Ich schreibe auch mal auf die Todo-Liste, place_rank im json-Format
zu exportieren.

Gruss

Sarah



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

Re: [Talk-de] nominatim json results Was: nominatim und Kreisfreie Städte

On Tue, Nov 05, 2013 at 05:10:48PM +0100, Florian Lohoff wrote:
 Ich habe gerade noch einen gefunden:
 
   Landwehr 8, 46569 Hünxe 
 
 gibt den Track Landwehr
 
   Landwehr 8a, 46569 Hünxe
   
 gibt nix zurueck.

Hier ist nicht die Hausnummer das Problem, sondern die PLZ. Nominatim
hat die so nicht drin und kann PLZs auch nicht ignorieren. Dass die
erste Anfrage funktioniert, liegt an einem anderen Bug, sollte also
eigentlich auch nicht gehen.

Ich kann nur empfehlen, PLZs bei der Adresssuche möglichst wegzulassen.
Die PLZs in Nominatim sind unvollständig und veraltet (Stand Sept. 2012).
Das zu fixen ist ganz oben auf der Todo-Liste, was aber im Augenblick
nicht viel bedeutet.

Gruss

Sarah

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

Re: [Talk-de] nominatim json results Was: nominatim und Kreisfreie Städte

On Tue, Nov 05, 2013 at 07:06:35PM +0100, Florian Lohoff wrote:
 On Tue, Nov 05, 2013 at 05:59:20PM +, Sarah Hoffmann wrote:
  On Tue, Nov 05, 2013 at 05:10:48PM +0100, Florian Lohoff wrote:
   Ich habe gerade noch einen gefunden:
   
 Landwehr 8, 46569 Hünxe 
   
   gibt den Track Landwehr
   
 Landwehr 8a, 46569 Hünxe
 
   gibt nix zurueck.
  
  Hier ist nicht die Hausnummer das Problem, sondern die PLZ. Nominatim
  hat die so nicht drin und kann PLZs auch nicht ignorieren. Dass die
  erste Anfrage funktioniert, liegt an einem anderen Bug, sollte also
  eigentlich auch nicht gehen.
  
  Ich kann nur empfehlen, PLZs bei der Adresssuche möglichst wegzulassen.
  Die PLZs in Nominatim sind unvollständig und veraltet (Stand Sept. 2012).
  Das zu fixen ist ganz oben auf der Todo-Liste, was aber im Augenblick
  nicht viel bedeutet.
 
 D.h. addr:postcode wird ignoriert sondern es werden die plz polygone
 verwendet?

Beim Erstimport letztes Jahr wurden PLZ-Centroiden aus den damals vorhandenen 
addr:postcode-Tags berechnet. Das ist so ziemlich alles, was verwendet wird.

Sarah

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

Re: [Talk-de] nominatim und Kreisfreie Städte

On Tue, Nov 05, 2013 at 05:52:41PM +0100, Martin Koppenhoefer wrote:
 Ich habe ein ähnliches Problem (naja) bei Tübingen, das einerseits
 Universitätsstadt ist (admin_level=8) andererseits auch Regierungsbezirk
 (admin_level=5). Wenn ich nun ins Suchfeld Olgastraße 8, Tübingen
 eingebe, wird der Regierungsbezirk präferiert (in D. ziemlich unüblich,
 eine Adresse über den Reg.bez. zu definieren ohne Stadt), und ich bekomme
 lauter Treffer, die gar nicht in Tübingen liegen sondern irgendwo im
 Regierungsbezirk d.h. evtl. auch 100km entfernt. Für ein brauchbares
 Suchergebnis muss ich die Postleitzahl hinzufügen, seltsamerweise geht
 olgastr. 8,  tübingen, tübingen auch nicht (was aber auch nicht viel
 bringen würde, so sucht wohl kaum jemand).

Es wird nichts präferiert, das ist genau das Problem. Die Suchbegriffe
für den Adresseteil kommen ungeordnet daher und dann passt Tübingen eben
genausogut wie Regierungsbezirk Tübingen und die Reihenfolge der Ergebnisse
ist willkürlich. 

 Ebenfalls seltsam ist, dass bei einer Suche nach Tübingen der
 Regierungsbezirk dann wiederum nicht unter den ersten Ergebnissen auftaucht
 (der Landkreis allerdings schon).

Das ist nicht seltsam, weil für den Namensteil (nicht aber den Addressteil, 
s.o),
perfekt passende Ergebnisse bevorzugt werden. Wenn es welche gibt, kommen
partielle Namen nicht in den ersten Hits vor.

 Prinzipiell sollte man m.E. auch die name-tags mal durchgehen, für einen
 admin_level 8 gehört m.E. ein Landkreis (bzw. Kreisfreie Stadt oder was
 es ist) zum Namen dazu, oder was meint Ihr?

Ich bin da etwas gespalten. Normalerweise würde ich sehr resolut sagen,
dass Typenangaben im name-Tag nichts zu suchen haben. Im Fall der
Regierungsbezirke entschärft es aber obriges Problem ein bisschen,
das Präfix dabeizuhaben (ohne Präfix würde die richtige Adresse nicht
einmal in der Liste auftauchen). Es bleibt aber trotzdem ein böser Hack für
einen Bug in der Suchmaschine.

Gruss

Sarah

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

Re: [Talk-de] Amtliche Daten

2013-10-29 Diskussionsfäden Sarah Hoffmann

On Tue, Oct 29, 2013 at 08:17:23AM +0100, Florian Lohoff wrote:
 On Tue, Oct 29, 2013 at 07:40:26AM +0100, Simon Poole wrote:
  Nominatim unterstützt mindestens alt_name, short_name, official_name und
  noch ein paar andere Tags neben name.
 
 alt_name auch mit Semikola?

Ja. 


Sarah


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

[Talk-de] Freiwilliger für Workshop mit Wanderverein gesucht

2013-10-19 Diskussionsfäden Sarah Hoffmann

Hallo,

vor einigen Tagen ist der Deutsche Wanderverein an mich herangetreten,
weil es ein neues Projekt zur kooperativen Datenerfassung gibt, bei dem
sie gerne nocheinmal prüfen würden, inwiefern sich OSM dabei integrieren
lässt. Für uns wäre das eine gute Gelegenheit, für eine Öffnung der
Wanderwegedaten für OSM zu diskutieren.

Als Modellregionen für das Projekt wurden das Altmühltal und der
Naturpark Kellerwald-Edersee gewählt. Anfang nächsten Jahres gäbe
es einen Workshop, bei dem wir OSM den Verantwortlichen näherbringen
könnten. Es wäre natürlich nicht schlecht, wenn das ein Mapper aus
den betreffenden Regionen wäre oder zumindest jemand, der sich etwas
besser mit dem Wanderwege-Mapping in Deutschland auskennt.

Wenn jemand Interesse hat, bei so einem Workshop aufzutreten, bitte
bei mir melden, ich kann das dann entsprechend weiterleiten.

Gruss

Sarah


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

Re: [Talk-de] Rendering Workshop (was: Hack-Weekend Karlsruhe 5./6. Oktober)

2013-08-21 Diskussionsfäden Sarah Hoffmann

On Tue, Aug 20, 2013 at 08:17:12PM +, Sven Geggus wrote:
 Im Rahmen dieses Events würde ich gerne zusammen mit Interessierten
 an Sachen arbeiten, die man für das Rendering von Karten (egal ob mit
 Mapnik oder Mapserver) immer wieder braucht und trickreich in der
 PostgreSQL Datenbank lösen kann.
 
 Und ich möchte endlich meine Topokarte auf Basis der Karte von Max Berger
 (http://geo.dianacht.de/topo/ 
 http://wiki.openstreetmap.org/wiki/User:Maxbe/Kartenversuch) 
 fertig kriegen.
 
 BTW, mein aktueller (lauffähiger) Stand (Mapfile und SQL scripten) ist
 unter git://git.geggus.net/topomap.git zu finden.
 
 Weil das Ganze wie die normale Mapnik-Karte auf permanent
 aktualisierten Daten aufbauen, mit Tirex laufen und weltweit zur
 Verfügung stehen soll kann ich (im Gegensatz zu Max, der nur einen
 vergleichsweise kleinen Ausschnitt rendert) keine weiteren
 Vorverarbeitungsschritte nach osm2pgsql brauchen.  Das Ganze muss
 komplett in den Datenbankabfragen passieren!

Bist du sicher, dass Vorverarbeitung nicht am Ende weniger
Ressourcen braucht?

 Spontan fallen mir folgende Dinge ein:
 
 * Berggipfel nach Prominenz rendern (Einbeziehung von Höhenlinien)
   (fertig siehe git)
 * Geniale Beschriftung von Gebirgen nach der Idee von Max
   (TODO siehe Wiki)
 * Internationalisierung/Latinisierung von Namen
   (erste Version siehe Karte auf http://openstreetmap.de/karte.html)

Es gab mal Diskussionen, die Importance-Rankings von
Nominatim zu benutzen, um Orte nach Prominenz zu rendern. Vielleicht
wäre das auch was. Entsprechende Daten könnte ich bereitstellen.

Sarah


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

Re: [Talk-de] Autokennzeichen

2013-08-12 Diskussionsfäden Sarah Hoffmann

On Sun, Aug 11, 2013 at 11:53:35PM +0200, Masi Master wrote:
 Am 09.08.2013, 10:19 Uhr, schrieb Sarah Hoffmann lon...@denofr.de:
 
 On Fri, Aug 09, 2013 at 09:33:20AM +0200, Roland Olbricht wrote:
für Nominatim hat jemand den Featurewunsch geäussert, dass
 es doch die
Suche nach deutschen Autokennzeichen unterstützen möge.
 Finde ich jetzt
keine schlechte Idee, weil die Kennzeichen ja im Prinzip
 als ref für die
Kreise dienen.
 
  Berlin macht das bereits so, mit dem Erfolg, dass jetzt solche
 Suchergebnisse
  herauskommen:
 http://nominatim.osm.org/search.php?q=berlinaccept-language=xx
 
 Sämtliche Bundesländer (und auch die in Italien) tragen solche
 Abkürzungen.
 Genauer: Beim Sichten der Einträge in Admin-Level 4 und 6 hat
 sich herausgestellt,
 dass da bis auf je eine Relation immer Abkürzungen drinstehen.
 
 Das liegt daran, dass der Nutzer MasiMaster die vor einer Woche dort
 alle angefügt hat:
 http://www.openstreetmap.org/browse/changeset/17204949
 
 Die ersten Beschwerden gab es eine Stunde später. ;)
 
 Ups, Beschwerden wollte ich keine auslösen!

Alles wieder gut. Mit den Kürzeln im ref-Tag stimmt das hier wieder:
http://nominatim.osm.org/search.php?q=berlinaccept-language=xx

und die Schnellsuche geht auch immernoch:

http://nominatim.osm.org/search.php?q=b

 Mein Vorgehen was so:
 Ich suchte einen kleinen Ort bei mir in der Nähe (der x-mal in DE
 vorkommt), wusste aber nicht in welchem Landkreis der war. Und die
 Suche mit: Ortsname, NRW lieferte kein Ergebnis zurück. Da ich mir
 (und anderen) den langen Namen Nordrhein-Westfalen ersparen wollte,
 hab ich die Abkürzung gesetzt. Denn irgendwann habe ich mitbekommen
 dass Nominatim auch short_name auswertet. Hat aber leider nicht
 funktioniert.

Das funktioniert schon, allerdings aktualisiert Nominatim die Adressen
der Orte in NRW nicht automatisch nach so einer 'kleinen' Änderung.
Das heisst im Suchindex fehlt die Abkürzung noch für die meisten Orte.
Das wird sich aber nach und nach ändern.

Gruss

Sarah

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

Re: [Talk-de] Autokennzeichen

2013-08-11 Diskussionsfäden Sarah Hoffmann

On Fri, Aug 09, 2013 at 11:31:33PM +0200, Michael von Glasow wrote:
 Der langen Rede kurzer Sinn: warum nehmen wir dieses Kürzel nicht
 einfach in den ref-Tag der jeweiligen Verwaltungseinheit auf? Die
 Litauer machen das schon (allerdings sind die Kürzel in OSM
 zweistellig und nicht mit denen im Kfz-Kennzeichen identisch). Die
 Amerikaner machen das gleiche mit den Kürzeln für ihre
 Bundesstaaten. In kleineren Zooms wird das dann auch gerendert und
 nimmt weniger Platz weg als der volle Name.

Das scheint mir der kleinste gemeinsame Nenner der Diskussion zu sein.
Ich werde also das Nominatim-Trac-Ticket mit den entsprechenden Hinweis
schliessen und, wenn es nicht noch Enwände gibt, die short_name-Tags
an den Bundesländern in ref-Tags ändern.

Sarah

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

Re: [Talk-de] Autokennzeichen

2013-08-09 Diskussionsfäden Sarah Hoffmann

Hallo,

On Fri, Aug 09, 2013 at 06:02:21AM +0200, Roland Olbricht wrote:
  für Nominatim hat jemand den Featurewunsch geäussert, dass es doch die
  Suche nach deutschen Autokennzeichen unterstützen möge. Finde ich jetzt
  keine schlechte Idee, weil die Kennzeichen ja im Prinzip als ref für die
  Kreise dienen.
  
  Dieses Tag finde ich
  weniger unterstützenswert, weil es a) von einem speziellen Import
  stammt und damit spezifisch nur für die deutschsprachige Region gilt,
 
 Außerdem der deutschsprachigen Region haben die Autokennzeichen oft keinen 
 geographischen Bezug. Beispiele sind die NL (gar kein Bezug) oder Frankreich 
 (letzte 2 Ziffern gleich Departement, sonst kein Bezug).
 
 Das globale Äquivalent dürfte allgemein eine Abkürzung des Städtenamens sein. 
 short_name hat immerhin über 11000 Verwendungen, davon bereits 120 auf 
 Relationen mit admin_level=6. Ich denke, das sinnvollste wäre, das zu 
 verwenden und die deutsche Community aufzufordern, das Autokennzeichen, das 
 ja 
 als Abkürzung dient, dort einzutragen.

Berlin macht das bereits so, mit dem Erfolg, dass jetzt solche Suchergebnisse
herauskommen: http://nominatim.osm.org/search.php?q=berlinaccept-language=xx

Bisher wurde short_name eigentlich eher da verwendet, wo eine kürzere aber
immernoch lesbare Version des Namens gebräuchlich ist. Also:
Rothenburg ob der Tauber - Rothenburg
Casper-David-Friedrich-Strasse - CD-Friedrich-Strasse

Deshalb zieht Nominatim das short_name-Tag dem name-Tag bei der Anzeige vor.
Wenn short_name mit Kürzeln gefüllt wird, ist das leider nicht mehr möglich.

Solche Kürzel gehören eher in ein ref-Tag. 

Sarah

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

Re: [Talk-de] Autokennzeichen

2013-08-09 Diskussionsfäden Sarah Hoffmann

On Thu, Aug 08, 2013 at 10:51:51PM +0200, Peter Wendorff wrote:
 Hallo Sarah,
 ich gebe zu Bedenken, dass ab Mitte 2014 wohl Autokennzeichen auch beim
 Umzug in einen anderen Kreis (auch über Landesgrenzen hinweg) behalten
 werden können, so dass die Information immer weniger wert sein dürfte.
 Dazu z.B. [1].
 Ich bin mir nicht sicher, ob das mittlerweile auch durch den Bundesrat
 durch ist, aber inwiefern es dann noch viel nützt, halte ich doch für
 fraglich.

Das wäre ja unerheblich, weil das Kennzeichen immernoch einen Heimatort
hat und es hier eher um die Verwwendung des Kennzeichens als Kürzel für
den Ort geht, nicht darum anhand eines Nummernschildes herauszufinden,
wo der Halter wohnt.

Auch das Argument, dass man nicht alle kennen kann, zählt nicht wirklich.
Zumindest die grossen Städte und die Kennzeichen der näheren Umgebung
hat man schon im Kopf und verwendet die auch. 

Aber wenn die Zuordnung von Kreis und Kennzeichen so nicht mehr gilt,
dann macht es vermutlich tatsächlich wenig Sinn, das als Autokennzeichen
zu taggen. Etwas Richtung 'ref' für allgemein bekannte Kennzeichen
klingt wie der bessere Weg.

 Ansonsten kann man das natürlich machen, wenn es nicht so viel Aufwand
 ist für die Entwicklung in Nominatim - ob es sich allerdings lohnt...
 Zumal in anderen Ländern die Kennzeichenregeln nochmal völlig
 unterschiedlich sein dürften.

Ist ein Einzeiler, aber das Ziel ist, die Spezialbehandlungen auf ein
Minimum zu reduzieren. Und so wichtig ist das ja nicht.

Sarah


 Am 08.08.2013 22:00, schrieb Sarah Hoffmann:
  Hallo,
  
  für Nominatim hat jemand den Featurewunsch geäussert, dass es doch die
  Suche nach deutschen Autokennzeichen unterstützen möge (siehe
  https://trac.openstreetmap.org/ticket/4936). Finde ich jetzt keine
  schlechte Idee, weil die Kennzeichen ja im Prinzip als ref für die
  Kreise dienen.
  
  Das Problem ist, dass die Kennzeichen zum grössten Teil nur unter
  openGeoDB:license_plate_code zu finden sind. Dieses Tag finde ich
  weniger unterstützenswert, weil es a) von einem speziellen Import 
  stammt und damit spezifisch nur für die deutschsprachige Region gilt,
  b) die openGeoDB tags kaum jemand wirklich aktuell hält (ich
  habe eher das Gefühl, sie werden mehr und mehr gelöscht)und
  c) die Tags an place-Nodes hängen anstatt an den Kreis-Relationen,
  wo sie eigentlich hingehören.
  
  Ich habe gesehen, dass einige Kreis-Relationen schon einen Tag
  license_plate_code erhalten haben, aber lange noch nicht
  alle. Wäre das etwas, was man vielleicht offiziell machen könnte,
  oder gibt es vielleicht schon andere Vorschläge zum Mapping von
  Autokennzeichen, die ich übersehen habe?
  
  (Laut taginfo gibt es auch noch einen Tag vehicle_plate_code,
  der aber nur in Moldavien (oder Ukraine?) vorkommt. Vielleicht
  könnte man sich ja sogar auf eines weltweit einigen.)
  
  Gruss
  
  Sarah
  
  ___
  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

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

Re: [Talk-de] Autokennzeichen

2013-08-09 Diskussionsfäden Sarah Hoffmann

On Fri, Aug 09, 2013 at 09:33:20AM +0200, Roland Olbricht wrote:
für Nominatim hat jemand den Featurewunsch geäussert, dass es doch die
Suche nach deutschen Autokennzeichen unterstützen möge. Finde ich jetzt
keine schlechte Idee, weil die Kennzeichen ja im Prinzip als ref für die
Kreise dienen.
 
  Berlin macht das bereits so, mit dem Erfolg, dass jetzt solche 
  Suchergebnisse
  herauskommen: 
  http://nominatim.osm.org/search.php?q=berlinaccept-language=xx
 
 Sämtliche Bundesländer (und auch die in Italien) tragen solche Abkürzungen.
 Genauer: Beim Sichten der Einträge in Admin-Level 4 und 6 hat sich 
 herausgestellt,
 dass da bis auf je eine Relation immer Abkürzungen drinstehen.

Das liegt daran, dass der Nutzer MasiMaster die vor einer Woche dort
alle angefügt hat:
http://www.openstreetmap.org/browse/changeset/17204949

Die ersten Beschwerden gab es eine Stunde später. ;)

Die italienischen bestehen etwas länger, wurden aber genauso mal
irgendwann von einem einzigen Nutzer eingetragen.


  Bisher wurde short_name eigentlich eher da verwendet, wo eine kürzere aber
  immernoch lesbare Version des Namens gebräuchlich ist.
 
 Was ist mit NRW? Die Frage: Wo liegt NRW? würde ein Großteil der
 Bevölkerung mit dem Verweis auf Nordrhein-Westfalen beantworten. Dass
 Wo liegt B? weniger gängig ist, wäre ich bereit zu glauben.

NRW wird umgangssprachlich als Name etabliert, ist aber auch der
einzige. Wenn du NRW in diesem Sinne verwenden willst, dann aber bitte 
auch short_name=Meckpom.

 Man macht da allerdings ein sehr subjektives Fass auf. Verwiesen sei auf
 M'gladbach, was recht gebräuchlich ist für Mönchengladbach, im Gegensatz
 zum selteneren und eher missbilligten D'dorf und W'tal.

loc_name

 Gängig, auch auf Straßenschildern, sind hier z.B.
 K-Ehrenfeld
 W-Elberfeld
 BN-Auerberg
 MS-Hiltrup
 Ich würde es für einen Gewinn halten, wenn diese Strings auf die 
 entsprechenden
 Stadtteile auflösen, aber sehe jetzt auch keine sinnvolle Verallgemeinerung 
 auf
 außerhalb Deutschlands. Wenn man so ansetzt, wäre eben auch
 Tdf-Spich
 legitim (Tdf ist kein Autokennzeichen), und Kreiskennzeichen verweisen dann
 eher auf die Kreisstadt als auf den Gesamtkreis.
 
  Also:
  Rothenburg ob der Tauber - Rothenburg
 
 Auch auf admin_level=8 kommt short_name in dieser Verwendung nur selten
 (weniger als 10 mal) vor. Ich hielte es dann für das
 aussichtsreichste, ref gleichwertig zu unterstützen und dann alle Vorkommen
 von short_name zu sichten und in der Regel zu entfernen.

ref wird bereits unterstützt. 

Gruss

Sarah

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

[Talk-de] Autokennzeichen

2013-08-08 Diskussionsfäden Sarah Hoffmann

Hallo,

für Nominatim hat jemand den Featurewunsch geäussert, dass es doch die
Suche nach deutschen Autokennzeichen unterstützen möge (siehe
https://trac.openstreetmap.org/ticket/4936). Finde ich jetzt keine
schlechte Idee, weil die Kennzeichen ja im Prinzip als ref für die
Kreise dienen.

Das Problem ist, dass die Kennzeichen zum grössten Teil nur unter
openGeoDB:license_plate_code zu finden sind. Dieses Tag finde ich
weniger unterstützenswert, weil es a) von einem speziellen Import 
stammt und damit spezifisch nur für die deutschsprachige Region gilt,
b) die openGeoDB tags kaum jemand wirklich aktuell hält (ich
habe eher das Gefühl, sie werden mehr und mehr gelöscht)und
c) die Tags an place-Nodes hängen anstatt an den Kreis-Relationen,
wo sie eigentlich hingehören.

Ich habe gesehen, dass einige Kreis-Relationen schon einen Tag
license_plate_code erhalten haben, aber lange noch nicht
alle. Wäre das etwas, was man vielleicht offiziell machen könnte,
oder gibt es vielleicht schon andere Vorschläge zum Mapping von
Autokennzeichen, die ich übersehen habe?

(Laut taginfo gibt es auch noch einen Tag vehicle_plate_code,
der aber nur in Moldavien (oder Ukraine?) vorkommt. Vielleicht
könnte man sich ja sogar auf eines weltweit einigen.)

Gruss

Sarah

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

Re: [Talk-de] Wie Adressen richtig richtig mappen?

2013-06-24 Diskussionsfäden Sarah Hoffmann

On Mon, Jun 24, 2013 at 12:48:00PM +0200, Jo wrote:
 2013/6/24 Manuel Reimer manuel.s...@nurfuerspam.de
 
  Raimond Spekking raimond.spekking at gmail.com writes:
   Auch +10. Wobei ich mit Straßenrelationen noch nie so recht warum
   geworden bin.
 
  +100
 
  Zu aufwändig. Wenn ich irgendwo nur die Straßenrelationen sehe, dann
  trage
  ich die Tags nach und wo beides vorhanden ist und eine Korrektur fällig
  ist,
  korrigiere ich nur die Tags und lasse die Relationen links liegen.
 
  Werden die Relationen überhaupt von den gängigen Routing-Lösungen
  ausgewertet?
 
 
 Sowie ich es verstehe benutzt wenigstens Nominatim sie. 

Nun ja, es kann damit mehr oder weniger umgehen, aber vor allem beim Update
machen die Relationen immer wieder Probleme, weil es da einen Haufen von
unmöglichen Sonderfällen zu beachten gibt, die gar nicht alle abfangen 
werden können, weil sonst die Updates zu lange dauern würden. 

Sarah

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

Re: [Talk-de] openstreetmap.org: Nominatim und ein Bug?

2013-06-20 Diskussionsfäden Sarah Hoffmann

Hi,

On Thu, Jun 20, 2013 at 08:19:15PM +0200, Jimmy_K wrote:
 hat jemand eine Idee, warum ich bei der Suche Gänserndorf,
 Henri-Dunant-Straße, 1 ein Ergebnis geliefert bekomme und bei
 Gänserndorf, Henri-Dunant-Straße 1 (ohne Beistrich zwischen Straße
 und Hausnummer) nicht? Normalerweise ist dies doch egal.

Das ist ein (bekannter) Bug. Nominatim hat ein bisschen Probleme,
Henri-Dunant-Straße 1 zu zerlegen und hört auf, bevor er zur
richtigen Teilung kommt. Das Komma hilft da, weil es so eindeutig
wird.

 2. Wenn ich in das Suchefeld etwas eingebe, läuft der Text hinter
 das Lupen-Symbol, ist dies bei euch reporoduzierbar? (FF 21 Win7)

Ist bei mir auch so. Ich würde fast denken, dass das von den Designern 
so gewollt ist.

Sarah

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

Re: [Talk-de] osm website: Schnellsuche Firefox

2013-06-06 Diskussionsfäden Sarah Hoffmann

On Thu, Jun 06, 2013 at 05:48:26PM +0200, Martin Raifer wrote:
 Warum geht das nicht automatisch? Soll ich bei Mozilla einen Bug
 melden, oder liegt das an der OSM seite?
 
 Nein, es liegt schon an der Art und Weise wie die Suche auf osm.org
 aktuell implementiert ist. Im Prinzip könnte das aber auch anders
 gelöst werden, sodass das Erstellen einer direkt-Suche wieder
 automatisch möglich ist - und wenn mich nicht alles täuscht war es
 das früher auch.

Ich würde mich da eher bei Firefox beschweren. Da hat man nun
den OpenSearch-Standard erfunden und anstatt diese Information
zu benutzen, parst es da irgendwelche URLs aus dem Formular.

Der OpenSearch-Standard ist auf osm.org korrekt implementiert und 
funktioniert mit Firefox auch problemlos:

- auf osm.org gehen
- DropDown-Menu in der Suchbox öffnen, dort OpenStreetMap
  wählen und schon hat man Direktsuche.

Wenn es auch noch ein Shortcut sein soll, einfach in besagtem
DropDown-Menu Suchmaschinen verwalten wählen und in der
Dialogbox das passende Schlüsselwort eintragen.

Sarah

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

Re: [Talk-de] Nominatim: addr:street ohne zugehörigen highway

2013-05-03 Diskussionsfäden Sarah Hoffmann

jotpe wrote:
es gibt Fälle in denen ein Gelände als Adresse einen Straßennamen hat, zu
der keine gleichheißende Straße existiert.

Beispiel:
Die Oberfeldwebel-Schreiber-Kaserne hat laut
http://www.deutschesheer.de/portal/poc/heer?uri=ci:bw.heer.dienstst.dfbrig.truppenteile.husrgt.anfahrt
die Adresse Talmannsberg 2, 78194 IMMENDINGEN. Trägt man
addr:street=Talmannsberg ein, wie gesagt, ohne zugehörigen highway mit
name=Talmannsberg in der Nähe, kann die Adresse nicht gefunden werden.
Die Nominatim-Analyse
http://nominatim.openstreetmap.org/details?osmtype=Nosmid=2195308806
des Adress-Nodes zeigt, dass der Name der Straße Bildstöckle nebendran
genommen wird.
Das Nominatim FAQ http://wiki.openstreetmap.org/wiki/Nominatim/FAQ sagt
dieses Verhalten auch vorraus.

Was kann ich aber tun um das Gelände mit der richtigen Adresse dennoch
finden zu können?

Nominatim unterstützt jetzt Addressen ohne Strasse via addr:place-Tag.[1]
Einfach das addr:street-Tag weglassen und stattdessen ein addr:place
hinzufügen mit dem Namen des Ortes, wo die Addresse dazugehört.

Aus technischen Gründen muss der Ort ebenfalls irgendwie gemappt sein.
Das kann eine admin-Boundary Level 8 und grösser sein, eine place-Node
für kleinere Orte (z.B. village, hamlet, locality) oder auch eine
benannte landuse. Mit letzterer sollte sich das Addressierungsproblem
in Mannheim lösen lassen. Die Planquadrate sind ja bereits gemappt.
Einfach noch ein landuse=commercial/residential/... dazufügen, den
Addressen ein entsprechendes addr:place geben und es sollte funktionieren.

Gruss

Sarah

[1] http://wiki.openstreetmap.org/wiki/Key:addr:place

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

Re: [Talk-de] Nominatim: addr:street ohne zugehörigen highway

2013-05-03 Diskussionsfäden Sarah Hoffmann

On Fri, May 03, 2013 at 02:43:04PM +0200, Martin Raifer wrote:
 Nominatim unterstützt jetzt Addressen ohne Strasse via addr:place-Tag.[1]
 Einfach das addr:street-Tag weglassen und stattdessen ein addr:place
 hinzufügen mit dem Namen des Ortes, wo die Addresse dazugehört.
 
 Super!
 
 Funktioniert das auch zusammen mit associatedStreet-Relationen? So
 wie hier: [1]. Oder müsste man dafür erst noch eine
 associatedPlace-Relation erfinden?
 
 [1] http://www.openstreetmap.org/browse/relation/2456314

Address-Relationen werden zur Zeit nicht unterstützt. Da scheint
es auch noch kein definieres Tagging-Schema zu geben.
Bei der associatedStreet-Relation wird die Strasse ja als Mitglied
mit einer entsprechenden Rolle eingetragen. Für Addressen ohne Strasse
müsste man dann entsprechend die Strassen rausnehmen und die Place-Node
oder Admin-Boundary mit einer anderen Rolle eintragen. Die Wiki-Seite
von addr:place schlägt ein vages 'object' vor. Das scheint aber laut
Taginfo noch nicht wirklich verwendet zu werden.

Sarah

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

Re: [Talk-de] Nominatim: addr:street ohne zugehörigen highway

2013-05-03 Diskussionsfäden Sarah Hoffmann

On Fri, May 03, 2013 at 04:10:39PM +0200, Andreas Neumann wrote:
 On 05/03/2013 03:49 PM, Martin Raifer wrote:
  Am 03.05.2013, 15:38 Uhr, schrieb Martin Koppenhoefer
  dieterdre...@gmail.com:
 
  man könnte auch versuchen, die restlichen Mapper zum Umtaggen zu
  addr:place bewegen, mehrere taggingvarianten für dasselbe
  verkomplizieren die Sache doch nur unnötig.
 
  Naja, addr:place und addr:hamlet/suburb/... sind doch zwei
  verschiedene Tagging-Konzepte. z.B. kann man addr:hamlet verwenden um
  zwischen zwei Hauptstraßen in der selben Gemeinde zu unterscheiden.
  Oder einfach als optionale zusätzliche geografische Information.
  addr:place hingegen wird anstelle von addr:street verwendet.
 
  Martin / tyr_asd
 
 dito! ich verwende addr:hamlet bzw. addr:suburb gerne um Ortsteile zu
 kennzeichnen. Besonders die erst vor kurzem eingemeindeten Ortsteile
 sind noch sehr stolz auf ihren Ortsnamen. Da ihre Adressen aber amtlich
 nun im neuen Ort gelistet sind, habe ich diesen Weg gewählt. Angezeigt
 wird dann meisten mit PLZ Stadt-Ortsteil

So verstehe ich das auch. addr:suburb kann mit oder ohne Strasse vorkommen.
Es funktioniert also wie addr:city und würde auch von Nominatim entsprechend
ausgewertet. Ich sehe gerade, dass es das noch nicht tut. Das kann man bei
Gelegenheit mal ändern.

Gruss

Sarah

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

Re: [Talk-de] Rechtschreibung und Zeichensetzung in den Karten

2013-04-17 Diskussionsfäden Sarah Hoffmann

On Wed, Apr 17, 2013 at 05:57:53PM +0200, Frederik Ramm wrote:
 On 04/17/2013 07:57 AM, NopMap wrote:
 Die Verwendung von einfachen  ist in der EDV und in digitalen Daten ein
 seit langem etablierter Standard. Die OSM DB ist ein EDV System und OSM XML
 ist ein digitales Austasuchformat.
 
 Find' ich auch.
 
 Wenn ueberhaupt irgendwo Anfuehrungszeichen in unseren Tags
 vorkommen, duerften sie in den wenigsten Faellen unveraenderliche
 Namensbestandteile sein, d.h. sie waeren dann auch den Regeln der
 Kontext-Sprache unterworfen und muessten ggf. in die entsprechenden
 englischen oder franzoesischen Anfuehrungszeichen umgesetzt werden.
 
 OSM ist kein Satzsystem, wir koennen ruhig das Zollzeichen
 benutzen. Ich schliesse mich aber der Frage an, wo die ueberhaupt
 vorkommen.

Es gibt nichts, was es nicht gibt. Gerade dieses Wochenende gefunden:
http://osm.lonvia.de/stuff/via_alla_bola.jpg

Man beachte die Zollzeichen. ;) 

Gruss

Sarah

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

Re: [Talk-de] Nominatim: addr:street ohne zugehörigen highway

2013-04-15 Diskussionsfäden Sarah Hoffmann

On Mon, Apr 15, 2013 at 12:54:09PM +0200, jotpe wrote:
 Weiteres Beispiel:
 zur Stadt Kaufbeueren gehört administrativ das kleines Dörfchen Märzisried.
 Alle Gebäude dort haben als Straßenname Märzisried, wobei keine
 gleichnamige Straße, sondern nur das Dorf place=hamlet existiert. Das
 entspricht auch dem amtlichen Daten.
 Suche ich nach Apfeltranger Straße 15, 87600 Kaufbeueren findet
 Nominatim2 Einträge.
 1. Das Haus das eigentlich Märzisried 15, 87600 Kaufbeuren ist aber wg.
 der fehlenden gleichnamigen Str. als Apfeltranger Straße aufgelöst wird.
 2. Danach erst das eigentlich gemeinte Haus, dass etwa 2,5 km NO entfernt
 liegt.
 
 Ist jemandem bekannt, ob bereits ein entsprechendes Ticket um dieses
 Problem zu beheben, existiert?

https://trac.openstreetmap.org/ticket/3425

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

2013-01-31 Diskussionsfäden Sarah Hoffmann

On Thu, Jan 31, 2013 at 01:10:50PM +0100, jotpe wrote:
  Das klingt, als wenn du auf diesen bekannten Bug gestossen bist: 
  https://github.com/twain47/Nominatim/issues/31 
  https://github.com/twain47/Nominatim/issues/31
 
  Versuche mal den dort beschriebenen Workaround und lasse den Import
  mit --disable-token-precalc laufen.
 
 Ich habe mal nachgesehen, welcher SQL-Befehl zuviel Speicher
 allokiert. In der data/words.sql
 ist es der Befehl in Zeile 49637 mit der hstore-Funktion svals. 

Ja, irgendwie scheint Postgrees da einen falschen Query-Plan zu
erstellen, aber nicht auf allen Systemen. Bei mir läuft es mit 32GB RAM
problemlos durch ohne zu swappen.

 Versuchshalber habe ich den SWAP stark vergrößert. Der SQL Statement
 forderte 80GB
 Swap und lief durch.

Eigentlich sollte Postgres soetwas intern auf der Platte zwischenspeichern
und nicht endlos Speicher allokieren.

 In der setup-Hilfe steht zu dem Schalter --disable-token-precalc Disable name
 precalculation (EXPERT). Was kann denn die Nominatim-Installation später denn
 
 schlechter als mit? Hat Nominatim dann Probleme beim Bewerten  wie wichtig
 ein Suchwort ist und liefert ggf. schlechter Suchergebnisse?

Die Suchergebnisse sind genau die gleichen. Nur die Performance der Suche ist
ein klein wenig schlechter. Du kannst es also gefahrlos verwenden.

Gruss

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

2013-01-29 Diskussionsfäden 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] Nominatin Installation - Grenze für Stacktiefe überschritten

2013-01-23 Diskussionsfäden Sarah Hoffmann

On Wed, Jan 23, 2013 at 12:13:55PM +0100, Johannes Porstein wrote:
 Hallo zusammen,
 
 Debian Squeeze
 postgres Version 8.4
 Nominatim Version vom 21.Januar ebenso osm2pgsql

Nominatim unterstützt zwar offiziell noch postgres 8.4, aber wirklich
getestet ist das nicht mehr. Wenn du irgendwie auf 9.0 oder 9.1 wechseln kannst,
solltest du das tun. (Ich weiss, dass es einen Backport von postgres gibt,
weiss aber nicht, wie es mit postgis aussieht.)

 Während des Importvorgangs gibt es bezüglich dem Erreichen der Stackgrenze
 mehrere Fehlermeldungen. Ich habe den Wert zunächst einmal grundsätzlich in
 der postgresql.conf aktiviert und auf 2MB gesetzt, dann 8 und dann 16MB
 (System-Stacksize mit ulimit -s kb ). Ab 8MB trat der Fehler nur noch
 einmal auf, der Vorgang dauerte aber wesentlich länger.

Meine DB hier läuft auf der Standardeinstellung von 2MB. Das sollte also
eigentlich funktionieren. Gibt es im postgres-Log vielleicht noch
genauere Informationen? Der Teil des Logfiles, den du angehängt hast,
reicht leider nicht, um zu erkennen, welcher SQL-Aufruf genau versagt.

 Im Endeffekt kann ich nichts mit der search.php aus dem importierten
 OSM-File finden, auch wird in der search.php kein Datum des Index
 angezeigt. Hat jemand einen Tipp?

Bist du sicher, dass die Stackfehler die einzigen Fehler sind, die
auftreten? Es ist durchaus möglich, dass sie nur die Folge eines früheren
Fehlers sind. Kannst du ausserdem sichergehen, dass das Script tatsächlich
bis zum Ende gelaufen ist? Als letztes solltest du eine Reihe von
'CREATE INDEX' sehen.

Gruss

Sarah

 
 
 
 Die Ausgabe des
 
 ./utils/setup.php --osm-file koeln-regbez.osm.pbf --all
 
 Befehls spuckt soetwas aus, bricht jedoch nicht an der Stelle ab, sondern
 macht weiter.
 
 
 Reanalysing database...
 HINWEIS:   no notnull values, invalid stats
 ANALYZE
 PHP Warning:  pg_query(): Query failed: FEHLER:  Grenze fÃ¼r Stacktiefe
 Ã¼berschritten
 HINT:  ErhÃ¶hen Sie den Konfigurationsparameter Â»max_stack_depthÂ«,
 nachdem Sie sichergestellt haben, dass die Stacktiefenbegrenzung Ihrer
 Plattform ausreichend ist.
 ..
 SQL-Anweisung Â»SELECT   $1 in /home/eporstein/Nominatim/utils/setup.php on
 line 490
 ERROR: FEHLER:  Grenze fÃ¼r Stacktiefe Ã¼berschritten
 HINT:  ErhÃ¶hen Sie den Konfigurationsparameter Â»max_stack_depthÂ«,
 nachdem Sie sichergestellt haben, dass die Stacktiefenbegrenzung Ihrer
 Plattform ausreichend ist.
 
 PL/pgSQL function placex_insert line 83 at Zuweisung
 FEHLER:  Grenze fÃ¼r Stacktiefe Ã¼berschritten
 HINT:  ErhÃ¶hen Sie den Konfigurationsparameter Â»max_stack_depthÂ«,
 nachdem Sie sichergestellt haben, dass die Stacktiefenbegrenzung Ihrer
 Plattform ausreichend ist.
 
 
 es grüßt jotpe
 ___
 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] Straßen in Dresden nicht gefunden

2013-01-12 Diskussionsfäden Sarah Hoffmann

On Sat, Jan 12, 2013 at 11:35:02AM +0100, Simon Poole wrote:
 Lingnerallee, Dresden wird gefunden (was ja auch das ist was eingetragen
 ist).

Das Problem mit den Bindestrichen ist ein bekannter Bug 
(oder besser: fehlendes Feature ;) in Nominatim:

https://trac.openstreetmap.org/ticket/4572

Gruss

Sarah

 Am 12.01.2013 11:13, schrieb hha4491:
  Hallo Liste,
  wenn ich
  Dresden, Lingner[-]Allee oder
  Lingner[-]Allee, Dresden
  eingebe, wird nichts angezeigt, obwohl die Straße im Plan existiert.
  Außerdem ist das Eingabefeld viel zu klein, um längere Adressen
  aufzunehmen.
 
 
 
 ___
 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] Poster - war Best of OSM-Websiete

2012-11-06 Diskussionsfäden Sarah Hoffmann

On Tue, Nov 06, 2012 at 12:01:21AM +0100, Alexander Lehner wrote:
 Ich werde jetzt mal eine Deiner Karten in Druck geben - gibts in ner
 Web-Druckerei fuer knapp 30 EUR.
[...]
 
 Die Wanderwege sind OSM-Relationen.
 Die ueblichen Relationen-Tags fuer regionale, internationale etc.
 Wanderwege werden extrahiert. User 'lonvia' stellt diese Overlays
 bereit und ich fand sie fuer meinen Zweck sehr huebsch. Weiss aber
 nicht, wie er/sie das erstellt hat.

Der Code und Style dazu findet sich auf Github[1]. Man könnte sich
also seine eigene DB erstellen und das rendern. Die Symbole sind
zum grössten Teil bereits als Vektorgrafiken vorhanden.

Prinzipiell wäre ich auch nicht abgeneigt, eine Export-Funktion
für die Daten von der Website aus anzubieten. Müsste man sich
aber genau überlegen, wie sowas aussehen muss.

Sarah

[1] https://github.com/lonvia/waymarked-trails-site

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

Re: [Talk-de] Frage: GPX Track einer Relation extrahieren/runterladen?

2012-10-05 Diskussionsfäden Sarah Hoffmann

On Fri, Oct 05, 2012 at 02:37:49PM +0100, Kevin Halton wrote:
  From: Alexander Lehner leh...@edv-buero-lehner.de
 
  Super, danke! Das war genau, was ich gesucht habe.
  Verewigt:
  http://de.wikipedia.org/wiki/Isar-Radweg#Weblinks
 
 Obowhl dies sehr nützlich ist, sind solche direkten Links auf die GPX Dateien 
 leider von den Herstellern unerwunscht.
 Auf http://cycling.waymarkedtrails.org/de/help/legal steht:
 Die GPX-Dateien werden ausschließlich für Besucher dieser Seite zur 
 Verfügung gestellt. Automatische Downloads oder direkte Links von anderen 
 Seiten werden nicht toleriert.
  
 Keine Ahnung was nicht toleriert bedeutet

Ich auch nicht. ;) Da ist wohl die deutsche Übersetzung ein wenig zu
streng geraten. Muss man mal anpassen.

Aber im Prinzip ist der Hinweis schon korrekt. Mit dem neuen Server
ist das zwar alles nicht mehr ganz so kritisch, aber dennoch würde
ich es vorziehen, wenn statt der direkten Links auf die GPX-Dateien
auf die Karte mit der Route verlinkt wird, also nach
http://cycling.waymarkedtrails.org/de/relation/2119154

Das ist nur ein Mausklick mehr für den Nutzer, um zum GPX zu kommen.

Gruss

Sarah
(Hersteller der Karte)

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

Re: [Talk-de] Update von nominatim.osm.org

2012-10-03 Diskussionsfäden Sarah Hoffmann

On Wed, Oct 03, 2012 at 05:19:24PM +0200, Eckhart Wörner wrote:
 Hallo Sarah,
 
 Am Dienstag, 11. September 2012, 18:31:15 schrieb Sarah Hoffmann:
   bin mir immer noch nicht sicher, warum es nicht funktioniert. Beispiel 
   Aystetten:
   Suche ( http://nominatim.openstreetmap.org/search.php?q=Aystetten ) 
   liefert sowohl Relation als auch Knoten, aber:
   
   – die Relation und der Knoten heißen gleich
   – die Relation ( http://www.openstreetmap.org/browse/relation/44 ) 
   enthält den Knoten mit Rolle label
   – die Änderungen sind schon vor ein paar Tagen passiert
  
  Es gab da noch ein Problem mit den Updates von Place-Boundary-Verbindungen.
  Im Code ist das bereits repariert, aber der OSM-Server wird erst in
  ca. 2 Wochen das nächste Software-Update erhalten. Es wird wegen dem
  Lizenzwechsel auch nochmal einen Neuimport der Datenbank geben in naher
  Zukunft. Spätestens dann sollten deine Änderungen sichtbar sein.
 
 ich nehme an, den Neuimport hat es schon gegeben? Das Beispiel funktioniert 
 leider immer noch nicht.

Der Neuimport steht leider immernoch aus. Wenn nichts dazwischen kommt,
wird es wohl übernächstes Wochenende passieren.

Gruss

Sarah

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

Re: [Talk-de] Update von nominatim.osm.org

2012-09-23 Diskussionsfäden Sarah Hoffmann

fly wrote:
On 09/09/12 01:46, Sarah Hoffmann wrote:
 On Sat, Sep 08, 2012 at 09:56:37PM +0200, fly wrote:

 Das war bisher der 1. Treffer:
 http://www.openstreetmap.org/browse/relation/1629146

 Sollte eigentlich alles soweit enthalten.
 
 Da hat sich in der Tat ein Bug eingeschlichen. Dass admin_level ohne ein
 boundary=administrative verwendet wird, war nicht vorgesehen.

Oh, dass habe ich wohl übersehen. Verstehe selber nicht warum das da fehlt, 
aber
lasse es erstmal so.

Wie sich herausstellte, war die Sache mit den Azoren noch etwas komplizierter.
Die Relation enthält eine label-Node, die keine Tags hat. Das hat Nominatim
verwirrt. Ich habe das jetzt gefixt, sodass er damit umgehen kann (wobei es 
allerdings zwei, drei Wochen brauchen wird, bis die Änderung auf dem 
Hauptserver ankommt).

Allerdings ist diese Art von Tagging IMHO doch eher fragwürdig. Die Label-Node
sollte schon eine normale place-Node sein und ausserdem innerhalb des Gebietes
liegen, die es beschreibt und nicht irgendwo im Meer. Das scheint mir zumindest
der Konsens anderswo zu sein.

Gruss

Sarah

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

Re: [Talk-de] Update von nominatim.osm.org

2012-09-11 Diskussionsfäden Sarah Hoffmann

Hi,

On Sun, Sep 09, 2012 at 05:03:06PM +0200, Stefan wrote:
 mir ist aufgefallen, dass eine Suche nach Fahltskamp[1] zwei
 Ergebnisse liefert. Eine in Pinneberg-Mitte und eine in Thesdorf.
 Dies ist aber nur eine (verbundene) Straße (in Pinneberg-Mitte). Die
 Unterteilung ist notwendig, da sich die oneway Eigenschaft ändert.
 
 Ist hier was an den Daten nicht richtig, oder kann nominatim damit nicht um?

Nominatim kann Duplikate schon erkennen, aber natürlich nur, wenn
sie im gleichen Stadtteil liegen. In diesem Fall ist das Problem,
dass die Stadtteile nur als place-Nodes vorhanden sind und er falsch
rät in welchem Stadteil der eine Teil der Strasse ist. Wenn du die
Stadtteile als boundary-Relationen einträgst, sollten die Duplikate
verschwinden.

Gruss

Sarah

 Am 26.08.2012 20:44, schrieb Sarah Hoffmann:
 Hi,
 
 wie einige vielleicht mitbekommen haben, hat Nominatim, die OSM-Suche, in
 den letzten Wochen ihre Updates ausgesetzt gehabt, um den Redaction-Bot
 passieren zu lassen. Inzwischen ist eine neue Datenbank eingespielt und
 die Suche ist wieder minuten-aktuell wie gewohnt.
 
 Bei dieser Gelegenheit hat der Server auch ein Software-Update bekommen.
 Neben kleineren Bugfixes gibt es drei grössere Neuerungen: die Art wie
 die Adressen ermittelt werden, wurde etwas verbessert, Orten wird
 jetzt mit Hilfe von Wikipedia-Artikeln eine Wichtigkeit zugeordnet
 und es gibt jetzt eine Erkennung wo Grenzrelationen und Place-Nodes
 zusammengehören.
 
 Ein paar kurze Worte zu den letzten beiden Punkten.
 
 Nominatim ermittelt jetzt mit Hilfe von Wikipedia-Artikeln, wie bekannt
 ein Ort ist und nutzt das, um die Reihenfolge zu verbessern, mit der
 die Suchergebnisse ausgegeben werden. Zum Beispiel liefert die Suche
 nach 'Brooklyn' jetzt tatsächlich als erstes Resultat den bekannten
 Stadtteil von New York und nicht irgendeinen Weiher im mittleren Westen
 der USA. Für die richtige Zuordnung der Orte hilft es ungemein, wenn
 das 'wikipedia'-Tag in einer seiner Varianten gesetzt ist. Sollten
 irgendwo also noch eine komische Reihenfolge bei der Suche herauskommen,
 erstmal schauen, ob das wikipedia-Tag noch fehlt.
 
 Für das Erkennen von Duplikaten bei Grenzrelationen und Place-Nodes
 wertet Nominatim jetzt sowohl die Rolle 'label' als auch 'admin_centre'
 in den Grenzrelatioen aus, wobei Nodes mit 'admin_centre' nur zusammengefasst
 werden, wenn Name und Admin-Level stimmen. Fehlen beide, rät Nominatim,
 welcher Place-Node zur Relation passen könnte. Das funktioniert aber nur
 beschränkt gut, weil es keine weltweit eindeutige Zuordnung zwischen
 admin-level und place-Wert gibt. Die Node explizit zur Relation
 zuzufügen ist daher zuverlässiger. Wenn für eine Grenzrelation ein
 Place-Node gefunden wurde, werden dessen Koordinaten auch als Zentrum
 der Relation zurückgegeben, was praktisch immer zu besseren Ergebnissen
 führt, als der Mittelpunkt der Relation, der bisher verwendet wurde.
 
 Bugs können wie üblich entweder im trac gemeldet werden oder aber auch
 gerne auf der geocoding Mailingliste diskutiert werden oder hier auf talk-de.
 
 An dieser Stelle noch einen Dank an alle, die bei dem Update mitgeholfen
 haben, insbesondere aber an Brian Quinion, der den Grossteil der Neuerungen
 implementiert hat.
 
 Gruss
 
 Sarah
 
 
 
 ___
 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

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

Re: [Talk-de] Update von nominatim.osm.org

2012-09-11 Diskussionsfäden Sarah Hoffmann

On Tue, Sep 11, 2012 at 07:31:23AM +0200, Eckhart Wörner wrote:
 Am Sonntag, 26. August 2012, 20:44:13 schrieb Sarah Hoffmann:
  Für das Erkennen von Duplikaten bei Grenzrelationen und Place-Nodes
  wertet Nominatim jetzt sowohl die Rolle 'label' als auch 'admin_centre'
  in den Grenzrelatioen aus, wobei Nodes mit 'admin_centre' nur 
  zusammengefasst 
  werden, wenn Name und Admin-Level stimmen. Fehlen beide, rät Nominatim, 
  welcher Place-Node zur Relation passen könnte. Das funktioniert aber nur
  beschränkt gut, weil es keine weltweit eindeutige Zuordnung zwischen
  admin-level und place-Wert gibt. Die Node explizit zur Relation
  zuzufügen ist daher zuverlässiger. Wenn für eine Grenzrelation ein
  Place-Node gefunden wurde, werden dessen Koordinaten auch als Zentrum
  der Relation zurückgegeben, was praktisch immer zu besseren Ergebnissen
  führt, als der Mittelpunkt der Relation, der bisher verwendet wurde.
 
 bin mir immer noch nicht sicher, warum es nicht funktioniert. Beispiel 
 Aystetten:
 Suche ( http://nominatim.openstreetmap.org/search.php?q=Aystetten ) liefert 
 sowohl Relation als auch Knoten, aber:
 
 – die Relation und der Knoten heißen gleich
 – die Relation ( http://www.openstreetmap.org/browse/relation/44 ) 
 enthält den Knoten mit Rolle label
 – die Änderungen sind schon vor ein paar Tagen passiert

Es gab da noch ein Problem mit den Updates von Place-Boundary-Verbindungen.
Im Code ist das bereits repariert, aber der OSM-Server wird erst in
ca. 2 Wochen das nächste Software-Update erhalten. Es wird wegen dem
Lizenzwechsel auch nochmal einen Neuimport der Datenbank geben in naher
Zukunft. Spätestens dann sollten deine Änderungen sichtbar sein.

Gruss

Sarah

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

Re: [Talk-de] Update von nominatim.osm.org

2012-09-08 Diskussionsfäden Sarah Hoffmann

On Sat, Sep 08, 2012 at 10:56:01AM +0200, Chris66 wrote:
 Hi,
 
 Suche nach Burgstraße, Bergkamen meldet 2 Treffer mit
 unterschiedlichen PLZ:
 
 44534 (falsch, Lünen)
 59192 (Bergkamen, korrekt)
 
 Bug in Nominatim oder Daten falsch ?
 
 Die PLZ/Admin Relation 158457 sieht mir ok aus.

Bug in Nominatim. PLZ sind zur Zeit noch sehr schlecht implementiert.
Ist aber recht weit oben auf der TODO-Liste.

Gruss

Sarah

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

Re: [Talk-de] Update von nominatim.osm.org

2012-09-08 Diskussionsfäden Sarah Hoffmann

On Sat, Sep 08, 2012 at 09:56:37PM +0200, fly wrote:
 On 06/09/12 15:48, Sarah Hoffmann wrote:
  On Thu, Sep 06, 2012 at 03:40:28PM +0200, fly wrote:
 
  Habe leider ein Problem entdeckt.
 
  Wenn ich azores bzw azoren eingebe bekomme ich leider viele Treffer. 
  Vor dem
  Update war der erste auch der richtige für das Archipel, jetzt ist er 
  leider gar
  nicht mehr vorhanden. Mit Glück findet man noch ein paar Treffer auf einer 
  der
  Inseln, aber auch sämtliche Inseln an sich werden auch nicht mehr 
  angeboten.
  
  Hast du gerade einen Link zum OSM-Objekt zur Hand, das er eigentlich finden 
  sollte?
  Damit liesse sich das leichter debuggen.
 
 Das war bisher der 1. Treffer:
 http://www.openstreetmap.org/browse/relation/1629146
 
 Sollte eigentlich alles soweit enthalten.

Da hat sich in der Tat ein Bug eingeschlichen. Dass admin_level ohne ein
boundary=administrative verwendet wird, war nicht vorgesehen.

Ich habe mal ein Ticket angelegt:
http://trac.openstreetmap.org/ticket/4558

Gruss

Sarah

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

Re: [Talk-de] Update von nominatim.osm.org

2012-09-07 Diskussionsfäden Sarah Hoffmann

Hi,

On Thu, Sep 06, 2012 at 04:07:15PM +0200, Eckhart Wörner wrote:
 Am Sonntag, 26. August 2012, 20:44:13 schrieb Sarah Hoffmann:
  Für das Erkennen von Duplikaten bei Grenzrelationen und Place-Nodes
  wertet Nominatim jetzt sowohl die Rolle 'label' als auch 'admin_centre'
  in den Grenzrelatioen aus, wobei Nodes mit 'admin_centre' nur 
  zusammengefasst 
  werden, wenn Name und Admin-Level stimmen.
 
 mir ist noch nicht ganz klar, wie das Zusammenfassen genau funktionieren soll.
 Beispiel Augsburg:
 Grenzrelation: 
 http://nominatim.openstreetmap.org/details.php?place_id=148614123
 Knoten: http://nominatim.openstreetmap.org/details.php?place_id=17722739
 
 - der Knoten ist admin_centre der Grenzrelation
 - beide heißen Augsburg
 - die Grenzrelation hat Admin Level: 6, der Knoten hat Admin Level: 15 (gibt 
 es doch gar nicht?)
 
 Sollte der Knoten auch admin_level=6 getaggt werden?

Ich würde in diesem Fall eher mit 'label' als Rolle taggen als mit 
'admin_centre',
weil Augsburg ja nicht das Verwaltungszentrum der kreisfreien Stadt ist, sondern
es ist ein und dieselbe Stadt. Dann ist es nicht nötig, dass admin levels
übereinstimmen.

Der Grund, dass Nominatim für admin_centre nach dem admin level sucht, liegt
daran, dass es nicht fälschlicherweise z.B. Kreis und Kreisstadt zusammenfassen
soll, wenn beide gleich heissen.

gruss

 Sarah

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

Re: [Talk-de] Update von nominatim.osm.org

On Mon, Aug 27, 2012 at 09:54:29AM +0200, Chris66 wrote:
 Am 26.08.2012 22:29, schrieb Sarah Hoffmann:
 
  Ich will jetzt keine Diskussion vom Zaun brechen, ob der Zusatz
  Spreewald nun in den name-Tag gehört oder nicht. 
 
 mMn nach ja, da das nunmal der offizielle Name ist.

Es gäbe noch die Möglichkeit, es so zu taggen:

name = Lübben
official_name = Lübben (Spreewald)

Ich würde jetzt nicht sagen, dass eine Variante richtiger ist
als die andere. Es kommt ganz auf den lokalen Gebrauch an.

  Eine Variante,
  um das Problem zu lösen ist, noch zusätzlich eine alt_name=Lübben
  oder short_name=Lübben zu ergänzen.
 
 Ah, beides wird also von Nominatim ausgewertet?

Ja, beides wird für die Suche verwendet. short_name wird zusätzlich
auch für die Anzeige in den Suchresultaten benutzt.

Zur Info, die anderen Namens-Tags die Nominatim zur Zeit versteht:
int_name, reg_name, nat_name, loc_name, old_name, commonname,
common_name, place_name, official_name

... und natürlich die ganzen Varianten mit Sprach-Code nach dem
Doppelpunkt.

Sarah

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

Re: [Talk-de] Update von nominatim.osm.org

On Mon, Aug 27, 2012 at 12:36:47PM +0200, Andreas Labres wrote:
 On 27.08.12 12:08, Sarah Hoffmann wrote:
  Es gäbe noch die Möglichkeit, es so zu taggen:
  name = Lübben
  official_name = Lübben (Spreewald)
 
 Berücksichtigt der Nominatim official_name (oder full_name oder alt_name oder
 loc_name oder was es da noch so gibt)?

Siehe Liste im zweiten Teil der Mail, die du da zitiert hast.

Sarah

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

Re: [Talk-de] Update von nominatim.osm.org

On Mon, Aug 27, 2012 at 01:46:21PM +0200, Martin Koppenhoefer wrote:
 
 
 
 
 Am 27.08.2012 um 13:00 schrieb Sarah Hoffmann lon...@denofr.de:
 
  Siehe Liste im zweiten Teil der Mail, die du da zitiert hast.
 
 Ist das für ref (nat_ref, old_ref etc.) auch implementiert? 

Ja, die hatte ich weggelassen. An ref-Tags wertet er noch
folgende aus:

  ref, int_ref, nat_ref, reg_ref, loc_ref, old_ref, 
  ncn_ref, rcn_ref, lcn_ref

Dann für die Flughäfen: 
  
  iata, icao

Und dann noch ein paar PLZ-Eigenartigkeiten: 

  pcode:1, pcode:2, pcode:3,
un:pcode:1,un:pcode2,un:pcode:3

Jetzt ist die Liste aber vollständig.

Sarah

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

Re: [Talk-de] Update von nominatim.osm.org

On Mon, Aug 27, 2012 at 12:20:53PM +, Sven Geggus wrote:
 Sarah Hoffmann lon...@denofr.de wrote:
 
  Nominatim ermittelt jetzt mit Hilfe von Wikipedia-Artikeln, wie bekannt
  ein Ort ist und nutzt das, um die Reihenfolge zu verbessern, mit der
  die Suchergebnisse ausgegeben werden. Zum Beispiel liefert die Suche
  nach 'Brooklyn' jetzt tatsächlich als erstes Resultat den bekannten
  Stadtteil von New York und nicht irgendeinen Weiher im mittleren Westen
  der USA.
 
 Hm, die Suche nach Goethestraße Karlsruhe liefert immer noch nicht das
 erwartete Ergebnis. Mit anderen Städten klappt es aber teilweise.

Das ist leider einer der Bugs, die immernoch auf der Todo-Liste stehen.
Das Ordnen hilft neustens bei weniger häufig verwendeten Namen, 
z.B. Schwindstr, Karlsruhe. Aber sobald es zu viele Kandidaten
gibt, kommt der richtige schon nicht aus der DB.

Sarah

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

Re: [Talk-de] Update von nominatim.osm.org

On Mon, Aug 27, 2012 at 02:35:45PM +0200, Markus wrote:
 Hallo Sarah,
 
 Nominatim ermittelt jetzt mit Hilfe von Wikipedia-Artikeln, wie bekannt
 ein Ort ist und nutzt das, um die Reihenfolge zu verbessern, mit der
 die Suchergebnisse ausgegeben werden.
 
 Das finde ich genial!
 
 Wie genau ermittelst Du diese Bekanntheit?

Der Code stammt nicht von mir, insofern weiss ich da auch nur sehr
wenig. Aber grob gesagt, ermittelt er die Wichtigkeit einer Wiki-Seite
über Link-Zähler und ähnliches und übernimmt dann diese Wichtigkeit
für das OSM-Objekt.

Wegen genauerer Details musst du Brian fragen.

Sarah

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

Re: [Talk-de] Update von nominatim.osm.org

On Mon, Aug 27, 2012 at 02:56:06PM +0200, tumsi wrote:
 Am 26.08.2012 20:44, schrieb Sarah Hoffmann:
 
 Hier noch 'ne Kleinigkeit die mir heuer aufgefallen ist:
 
 Die Stadt Lübben wird nur gefunden wenn man Lübben (Spreewald)
 in die Suchmaske eingibt. Könnte man noch verbessern.
 
 Die parallele Suchmaschine (GeoNames) kann es ja auch.
 
 Dieses Problem kenne ich auch und zwar mit Alfeld (Leine). Sucht man
 nur nach Alfeld, findet Nominatim erst einmal nur ein Kaff in Bayern
 und ein dazugehöriges Autobahnkreuz. Erst nach zweimaligem Mehr
 Treffer findet sich dann an der 6. Stelle die
 (Weltkulturerbe-)Stadt Alfeld (Leine). Das kann wirklich nicht
 sinnvoll sein.

Wie gesagt, ein zusätzliches alt_name-Tag schafft Abhilfe. Eventuell
auch noch ein wikipedia-Tag ergänzen. Es scheint, dass der Namenszusatz
auch verhindert, dass Nominatim die richtige Wikipedia-Seite findet,
die dem Ort eine höhere Wichtigkeit verleihen könnte.

 Auch finde ich es absurd, dass zuerst Verwaltungsgrenzen als Treffer
 angezeigt werden und erst später die zugehörige Stadt, Dorf etc.

An sich ist das schon richtig so, weil die Verwaltungsgrenzen eine
Fläche darstellen, die genauer besagt, wie gross der Ort eigentlich
ist. 

Das Problem hier ist eher die Benennung. Da diese Grenzen alle
mit boundary=administrative getaggt sind, gibt die Website auch
einfach nur Verwaltunsgrenze zurück. Das sollte man besser mit Hilfe
des admin-levels unterscheiden und dann entsprechend 'Stadt', 'Kreis',
'Land', etc. angeben. Dann machen die Ergebnisse mehr Sinn.

Das ist auf jeden Fall auf der Todo-Liste für die nächste Version.

Sarah

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

Re: [Talk-de] Update von nominatim.osm.org

On Mon, Aug 27, 2012 at 10:27:16PM +0200, Harald wrote:
 Zur Info, die anderen Namens-Tags die Nominatim zur Zeit versteht:
 int_name, reg_name, nat_name, loc_name, old_name, commonname,
 common_name, place_name, official_name
 
 ... und natürlich die ganzen Varianten mit Sprach-Code nach dem
 Doppelpunkt.
 
 
 Soll dass jetzt heißen, dass jeder in den name-tag schreiben kann,
 was er oder sie will? Ich war eigentlich immer der Meinung, da
 gehört der offizielle Name hin. Für einen abweichenden Gebrauch sehe
 ich keine stichhaltigen Gründe.

Die verschiedenen Varianten des Name-Tags sind ausreichend im
Wiki dokumentiert:
http://wiki.openstreetmap.org/wiki/DE:Names

Nominatim implementiert nur, was da steht. (Oder um genau zu sein:
was da stand, als die Liste angelegt wurde. Offensichtlich werden
einige Tags nicht länger verwendet. Könnte man mal korrigieren.)

Gruss

Sarah

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

[Talk-de] Update von nominatim.osm.org

2012-08-26 Diskussionsfäden Sarah Hoffmann

Hi,

wie einige vielleicht mitbekommen haben, hat Nominatim, die OSM-Suche, in
den letzten Wochen ihre Updates ausgesetzt gehabt, um den Redaction-Bot
passieren zu lassen. Inzwischen ist eine neue Datenbank eingespielt und
die Suche ist wieder minuten-aktuell wie gewohnt.

Bei dieser Gelegenheit hat der Server auch ein Software-Update bekommen.
Neben kleineren Bugfixes gibt es drei grössere Neuerungen: die Art wie
die Adressen ermittelt werden, wurde etwas verbessert, Orten wird
jetzt mit Hilfe von Wikipedia-Artikeln eine Wichtigkeit zugeordnet
und es gibt jetzt eine Erkennung wo Grenzrelationen und Place-Nodes
zusammengehören.

Ein paar kurze Worte zu den letzten beiden Punkten.

Nominatim ermittelt jetzt mit Hilfe von Wikipedia-Artikeln, wie bekannt
ein Ort ist und nutzt das, um die Reihenfolge zu verbessern, mit der
die Suchergebnisse ausgegeben werden. Zum Beispiel liefert die Suche
nach 'Brooklyn' jetzt tatsächlich als erstes Resultat den bekannten
Stadtteil von New York und nicht irgendeinen Weiher im mittleren Westen
der USA. Für die richtige Zuordnung der Orte hilft es ungemein, wenn
das 'wikipedia'-Tag in einer seiner Varianten gesetzt ist. Sollten 
irgendwo also noch eine komische Reihenfolge bei der Suche herauskommen,
erstmal schauen, ob das wikipedia-Tag noch fehlt.

Für das Erkennen von Duplikaten bei Grenzrelationen und Place-Nodes
wertet Nominatim jetzt sowohl die Rolle 'label' als auch 'admin_centre'
in den Grenzrelatioen aus, wobei Nodes mit 'admin_centre' nur zusammengefasst 
werden, wenn Name und Admin-Level stimmen. Fehlen beide, rät Nominatim, 
welcher Place-Node zur Relation passen könnte. Das funktioniert aber nur
beschränkt gut, weil es keine weltweit eindeutige Zuordnung zwischen
admin-level und place-Wert gibt. Die Node explizit zur Relation
zuzufügen ist daher zuverlässiger. Wenn für eine Grenzrelation ein
Place-Node gefunden wurde, werden dessen Koordinaten auch als Zentrum
der Relation zurückgegeben, was praktisch immer zu besseren Ergebnissen
führt, als der Mittelpunkt der Relation, der bisher verwendet wurde.

Bugs können wie üblich entweder im trac gemeldet werden oder aber auch
gerne auf der geocoding Mailingliste diskutiert werden oder hier auf talk-de.

An dieser Stelle noch einen Dank an alle, die bei dem Update mitgeholfen
haben, insbesondere aber an Brian Quinion, der den Grossteil der Neuerungen
implementiert hat.

Gruss

Sarah



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

Re: [Talk-de] Update von nominatim.osm.org

2012-08-26 Diskussionsfäden Sarah Hoffmann

On Sun, Aug 26, 2012 at 10:06:26PM +0200, Chris66 wrote:
 Am 26.08.2012 20:44, schrieb Sarah Hoffmann:
 
 Bei dieser Gelegenheit hat der Server auch ein Software-Update bekommen.
 
 Vielen Dank dafür.
 
 Hier noch 'ne Kleinigkeit die mir heuer aufgefallen ist:
 
 Die Stadt Lübben wird nur gefunden wenn man Lübben (Spreewald)
 in die Suchmaske eingibt. Könnte man noch verbessern.
 
 Die parallele Suchmaschine (GeoNames) kann es ja auch.

Sie wird schon gefunden, aber erst im zweiten Versuch, nachdem man
auf Mehr Treffer geklickt hat.

Der Grund dafür ist, dass Nominatim exakten Ergebnissen den
Vorzug gibt, was ja meistens auch das ist, was man eigentlich will.

Ich will jetzt keine Diskussion vom Zaun brechen, ob der Zusatz
Spreewald nun in den name-Tag gehört oder nicht. Eine Variante,
um das Problem zu lösen ist, noch zusätzlich eine alt_name=Lübben
oder short_name=Lübben zu ergänzen.

Gruss

Sarah

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

Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??

2012-07-18 Diskussionsfäden Sarah Hoffmann

Lieber Christian,

On Tue, Jul 17, 2012 at 04:09:55PM +0200, Christian Müller wrote:
 Apropos Nominatim - da könnte man erstmal is_in aufräumen..  Da werden 
 teilweise Gebiete nach ausdehnungslosen place=region nodes benannt, die 
 hunderte km von den Objekten, zu deren Bennenung sie herangezogen werden, 
 entfernt sind.  Das ist so gravierend, dass Mapper note= an ihre Gebiete 
 hängen, und sich fragen, warum nach dem vierten Komma ein Begriff steht, den 
 sie überhaupt nicht zuordnen können. 

Bei einer so freundlich und präzise formulierten Fehlermeldung kann 
ich natürlich nicht widerstehen, mich sofort darum zu kümmern. 

Lass mich nur gerade den Papierkorb unterm Schreibtisch hervorholen.

In diesem Sinne: *plonk*

Gruss

Sarah

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

Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??

2012-07-17 Diskussionsfäden Sarah Hoffmann

On Tue, Jul 17, 2012 at 02:11:37AM +0200, Stephan Wolff wrote:
 Wozu
 also die Relation? Nur fuer die fiktive Frage wie viele Strassen hat
 die Stadt?
 Für alle Fragen, die Straßen (im üblichen Sinn) betreffen:
 - Suche: Wo ist die ...straße? - Aktuell liefert Nominatim zu einer
   langen Straße oft mehrere Dutzend Treffer von OSM ways.
 Wenn Nominatim das entsprechend zusammenfassen kann (z.T. tut es das
 AFAIK), ist das auch da behoben.
 Die Abfrage Westring, Kiel liefert etwa 50 einzelne Straßensegmente.

Das Problem steht irgendwo auf der Todo-Liste. Die Lösung dazu wird aber
mit Sicherheit nicht aus der Auswertung irgendwelcher Strassenrelationen 
bestehen.

Gruss

Sarah

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

Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??

2012-07-10 Diskussionsfäden Sarah Hoffmann

On Mon, Jul 09, 2012 at 11:51:13PM +0200, Christian Müller wrote:
 Am 09.07.2012 21:47, schrieb Frederik Ramm:
  Ist halt die Frage, fuer wen. Fuer den Router und den Renderer eben
  nicht.
 
 Genau das ist der Punkt.  Schmeißen wir die Relationen weg, verprellen
 wir Anwender und Entwickler bestimmter Anwendungsfälle genau so, wie es
 Unkenrufe geben wird, wenn plötzlich Namen einer Straße aus mehreren
 Elementen nur noch in der Relation auftauchen.

Kannst du konkrete Beispiele nennen von Anwendern, die irgendeiner Relation
ausser den drei wirklich gebrauchten (Routen, Abbiegerelation,
Multipolygon) nachweinen würden?

Wie Jochen bereits gesagt hat, muss man für die meisten Sachen den
Fall ohne Relationen ohnehin implementieren, weil es dieser Fall
immernoch der häufiger gebrauchte ist.

 Mich hat bisher kein einziges Argument gegen Relationen überzeugt. 
 Einzig evtl., dass sie schlecht gepflegt sind - das gilt aber auch für
 den restlichen OSM-Datenbestand.  Ich sehe z.B. immer wieder nicht
 verbundene Nodes, versehentlich verschobene, etc.

Relationen sind wesentlich leichter versehnlich kaputt zu machen als
Nodes, Wege und Tags, weil sie unsichtbar im Hintergrund herumlungern
und man nicht sofort sieht, dass man da etwas ändert. 

 Ich kann auch Sarah's Argumenten nicht folgen, dass OSM eine rein
 spatiale DB ist.  Es ist ein Mix - whatever works entscheidet, wer wie
 etwas modelliert.  Natürlich bedeuten diese Freiheiten Komplexität in
 der Auswertung - das ist aber imho dennoch weniger Aufwand, als alle zu
 zwingen, einheitlich zu mappen.  Ein Einwirken auf jeden der dann nach
 Überlegung falsch mappt, wird denjenigen die Lust am Mappen verderben.

Wenn du dir zuviel dieser Freiheiten herausnimmst, schränkst du
gewaltig die Freiheiten der anderen Mapper ein. Siehe oben. Relationen
sind in erster Linie ein Hindernis für deine Mitmapper. Es geht nicht
darum, 'einheitlich' zu mappen, es geht darum, das ganze so einfach wie
möglich zu halten, damit es für alle verständlich bleibt.

Ausserdem sind Relationen ein Motivationskiller, wenn es darum geht 
Fehler zu korrigieren. Wer mag schon einen Weg anfassen, der Mitglied 
in 15 Relationen ist. Ein Weg mit 15 kryptischen Tags ist zwar auch 
ein bisschen lästig, aber normalerweise kann man die Tags einfach 
ignorieren, frei nach dem Motto 'leben und leben lassen'.

 Für mich bedeuten Relationen Flexibilität - u.U. oft auch, dass ein und
 der gleiche geografische Sachverhalt eben vielfältig modelliert werden
 kann.  Warum begreifen wir das nicht weiterhin als Chance?  Warum wird
 stattdessen der Perfektionismus in primitiveren, unstrukturierten Daten
 gesucht, wie es Knoten und Weg nunmal sind?

Geografische Sachverhalte sollte man über Geometrie ausdrücken und
nicht durch irgendwelche künstlichen Strukturen. Natürlich könnten
wir für jede Bushaltestelle eine Relation erstellen, die besagt, ob
sie jetzt rechts von der Strasse liegt oder links. Aber was ist der
Sinn? Diese Information ist bereits in der DB, das heisst die Relation
bringt absolut nichts.

 Relationen sind auch dort, wo eigentlich alles auf dem Weg getaggt
 werden könnte, eine sinnvolle Ergänzung, z.B. um die Übersichtlichkeit
 zu bewahren und die Pflege zu vereinfachen.  Sie können evtl. 50+
 Übersetzungen halten, während die bsp.-haften, sechs zugehörigen Wege
 nur den regional üblichen Namen halten.  Auch mit Lookup-Tables/LUT
 versagt irgendwann der minimalistische Ansatz.  Je nachdem, wieviel
 Information über eine Menge von Wegen oder Knoten gehalten werden soll. 
 Auch wenn LUT evtl. in einigen Software-Projekten anzutreffen sind und
 dort eine Tag-Redundanz erfolgreich wegoptimieren, sind sie kaum
 dokumentiert und die Art ihrer Implementierung variiert.  Die Live-DB,
 die Live-Toolchain verwendet sie nicht.  Zudem wird mit der Auslagerung
 von Tags in LUT auch nichts anderes als eine Relation geschaffen, halt
 nur nicht vom Menschen.

Jetzt wirfst du irgendwelche technischen Begriffe in den Raum ohne
dir wirklich mal einen Kopf gemacht zu haben, wie das ganze eigentlich
funktioniert. Redundanz in den Tags ist bisher einfach kein grosses Problem 
gewesen. Die Art und Weise wie Datenbanken das handhaben, ist effizient 
genug. Wir haben ganz andere Ecken, wo wir ernsthafte Probleme mit der
Effizienz bekommen. In erster Linie bei der Berechnung der Weggeometrien
und dem Node-Lookup. 

 Da die Daten, wie die Softwareprojekte drumrum vermutlich nie perfekt
 sind, ist das mehr an Information und evtl. auch Redundanz eine Chance,
 gute QM-Tools zu bauen.  Am Beispiel der Bundesstraßen z.B. könnte man
 die Argumente derjenigen aufgreifen, die meinen
 
 man könne den Verlauf der Bundesstraße auch programmatisch anhand
 des ref= zusammenbauen und braucht die Relation gar nicht
 
 und gegen das prüfen, was manuell gepflegt wird.  In der Summe ergibt
 das eine gewisse Robustness gegen die Fehler, die man beim Mappen machen
 kann:
 
 - versehentlich Relation beschädigen
 - versehentlich

Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??

2012-07-09 Diskussionsfäden Sarah Hoffmann

On Mon, Jul 09, 2012 at 01:20:51PM +0200, Frederik Ramm wrote:
 Bei Relationen ist wenigstens ein generischer Support moeglich -
 gaengie Editoren koennen Dir wenigstens sagen, dass da eine Relation
 ist, selbst wenn sie nicht wissen, was sie bedeutet. Aber wenn im
 XML halt ploetzlich ein area oder route oder turnrestriction
 auftaucht, fliegt Dir der XML-Parser entweder um die Ohren oder
 schmeisst das Ding ganz weg.
 
 Eventuell sollte man alle diese neuen Datentypen dann in irgendwas
 gleichartiges kapseln, so dass eine Software, die den Datentyp nicht
 versteht, nicht total aufgeschmissen ist *duck*

Genau aus diesem Grund finde ich Relationen so wie sie sind eigentlich
eine geniale Idee, einfach und flexibel. (Aauch in der Verarbeitung,
wenn man sich mal eine Minute von osm2pgsql lösen kann.)

Wir haben mit Relationen keine technisches Problem sondern
ein menschliches. Ein paar Powermapper meinen, dass jede Beziehung
von Objekten in der DB explizit mit Relationen modeliert werden müsse
und treten dabei dei eigentliche Idee von OSM mit Füssen, nämlich 
dass OSM eine spatiale DB ist und keine relationale.
Anstatt also zu überlegen, was man den Leuten alles
verbieten müsste, sollten wir die Mapper besser darüber aufklären,
warum ihre Relationsmania überflüssig und gefährlich ist.

Jans Frage am Anfang dieses Threads macht insofern überhaupt keinen
Sinn. Es ist komplett irrelevant, wie leicht oder schwer eine
Relation zu verarbeiten ist. Die einzige Frage, die er sich stellen
sollte ist die: ist die Relation wirklich nötig oder ist es möglich,
meine Information auch in Form von einfachen Tags und geografischen
Beziehungen in der DB unterzubringen. Die Antwort auf diese Frage
ist eindeutig, dass es möglich ist, und damit sollte die Sache 
erledigt sein.

Ähnliches gilt für Anwendungen, die hier in letzter Zeit diskutiert
wurden. (Ich denke mit Schaudern an den Thread zum Eisenbahn-Tagging.)
Redundanz ist kein Argument für Relationen. Ich weiss nicht, wie man
es anders in einer spatialen Datenbank verarbeiten kann ist kein Argument
für Relationen. Ich kann die Daten so leichter runterladen ist kein
Argument für Relationen. Das einzige relevante Argument ist: es geht nicht 
anders[1]. Und das sollten wir allen Mappern klar machen. Wie es
eine ungeschriebene on the ground-Regel gibt, sollten wir eine 
vermeide Relationen-Regel einführen und so oft wie möglich zitieren.

Wenn wir es schaffen mehr Selbstdisziplin zu üben und Relationen auf 
eine Handvoll klar definierter Anwendungsfälle zu begrenzen, braucht 
es keine Änderung an der API.

Gruss

Sarah

[1] Und bevor man mich jetzt zu sehr beim Wort nimmt: das schliesst
auch die Fälle ein, wo es zwar anders ginge, aber nur von hinten
durch die Brust etc.

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

Re: [Talk-de] ÖPNV-Karte in OpenLayers 2.12

2012-07-07 Diskussionsfäden Sarah Hoffmann

On Sat, Jul 07, 2012 at 11:49:42AM +0200, Frank wrote:
 Moin!
 Auf meiner Homepage habe ich eine OpenLayers-Karte, die umschaltbar
 ist zwischen verschiedenen OSM-Kartentypen.
 Ich möchte nun von OpenLayers 2.11 auf 2.12 aktualisieren.
 
 Ich habe den Code soweit bereinigt, dass keine Fehler mehr angezeigt
 werden, z.B. für ein KML-Overlay umgestellt von OpenLayers.Layer.GML
 auf _.Vector.
 
 Was nun noch nicht funktioniert, das ist die ÖPNV-Karte.
 Code wie bei den anderen Kartentypen und wie vorher bei OL 2.11:
 
 new OpenLayers.Layer.OSM(Ouml;PNV (Bus und Bahn),
  http://tile.memomaps.de/tilegen/${z}/${x}/${y}.png;,
  { numZoomLevels: 19, displayInLayerSwitcher: true, buffer: 0,
   attribution: attroepnv, keyname: 'oepnvde' }),
 
 Es werden keine Script-Fehler angezeigt aber es werden im Map-Rahmen
 nur rosafarbene Tiles angezeigt. Bei Einzel-Abruf kommt dann
 jedoch ein korrekter Tile.
 
 Was für ein Problem hat OpenLayers 2.12 mit der ÖPNV-Karte?
 Falsche Header?
 Hat jemand ähnliche Erfahrungen gemacht?

Das X-Origin-Handling hat sich geändert. Du musst noch folgendes 
in den Constructor einfügen:

   tileOptions: {crossOriginKeyword: null}

Also obrige Zeile muss heissen:

 new OpenLayers.Layer.OSM(Ouml;PNV (Bus und Bahn),
  http://tile.memomaps.de/tilegen/${z}/${x}/${y}.png;,
  { numZoomLevels: 19, displayInLayerSwitcher: true, buffer: 0,
tileOptions: {crossOriginKeyword: null},
   attribution: attroepnv, keyname: 'oepnvde' }),


Siehe Release-Notes: 
https://github.com/openlayers/openlayers/blob/master/notes/2.12.md#osm-and-bing-layers

Sarah

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

Re: [Talk-de] Hack-Weekend Karlsruhe und Administrative Grenzen / Hierarchien weltweit

2012-05-21 Diskussionsfäden Sarah Hoffmann

On Sun, May 20, 2012 at 11:52:47AM -0700, Kai Krueger wrote:
 
 Frederik Ramm wrote
  
  Was da fehlt, ist irgendein automatisches 
  Kontrollsystem, das all diese Grenzen prueft und z.B. auf Basis einer 
  naechtlichen Auswertungen Reports generiert
  
 
 Etwas aehnliches erzielt das mapquest open Broken polygon tool [1] das auf
 Basis von Nominatim funktioniert. Es listet Polygone die nicht korrekt sind
 (z.B. self-intersecting) oder bei denen sich die Flaeche drastisch
 geaendert hat, was meist auf einen Fehler hindeutet. Da administrative
 Grenzen natuerlich sehr wichtig fuer Nominatim ist, gibt es glaube ich auch
 eine Einstellung um nur administrative Polygone anzuzeigen.
 
 http://open.mapquestapi.com/brokenpoly/

Auf dem OSM-Nominatim-Server gibt es die gleiche Liste minuten-aktuell:

http://nominatim.openstreetmap.org/polygons

Um, die Anfrage auf administrative Polygone zu beschränken, kann man
den class-Parameter nutzen:

http://nominatim.openstreetmap.org/polygons?class=boundary

(auf alles, was mit boundary=* getaggt ist, um genau zu sein)

Standardmässig zeigt es nur die Polygone an, die im Laufe der letzten 
24 Stunden kaputtgegangen sind. Mit days=X kann das auf X Tage erweitert 
werden. Bitte diesen Parameter mit Verstand einsetzen.

Sarah

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

Re: [Talk-de] OT: OpenLayers Custom Build

2012-05-21 Diskussionsfäden Sarah Hoffmann

On Mon, May 21, 2012 at 05:32:39PM +0200, Sebastian Klemm wrote:
 Hallo,
 
 da hier ja auch einige OpenLayers-Anwender mitlesen, versuch ich es
 jetzt mal hier, nachdem ich auf der OL-Users-ML kein Glück hatte.
 
 Für eine Webanwendung möchte ich eine angepasste geschrumpfte Version
 der OL-Bibliothek erzeugen.
 Der Build-Prozess funktioniert soweit auch, jedoch unterscheidet sich
 das Verhalten der erzeugten Bibliothek in einer entscheidenden
 Kleinigkeit von der  Komplett-OpenLayers.js:
 
 Wenn ich im JavaScript mittels map.setCenter() den Kartenausschnitt am
 Anfang festlegen will, lande ich statt in Deutschland im Atlantik am
 Äquator. Die Koordinaten scheinen als Pixel statt Länge/Breite in Grad
 interpretiert zu werden.
 Das ist der verwendete Code, inkl. Transformation der Koordinaten:
 
 var center = new OpenLayers.LonLat(10, 50).transform(new
 OpenLayers.Projection(EPSG:4326), map.getProjectionObject());
 
 if (!map.getCenter()) {
  map.setCenter(center, 15);
 }
 
 Komischerweise funktioniert derselbe Code einwandfrei wenn ich die
 originale gebundelte OL-Lib verwende. Deshalb vermute ich, dass in
 meinem OL-Build irgendwas fehlt, obwohl mit dem vorhandenen Code keine
 JavaScript-Fehler ausgegeben werden.

Versuch mal, noch folgendes in [include] hineinzunehmen:

OpenLayers/Layer/SphericalMercator.js

Das enthält die nötigen Umrechnungsfunktionen zwischen 900913 und 4326.

Gruss

Sarah

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

Re: [Talk-de] Suche nach Elbufer, Bad Schandau

2012-05-04 Diskussionsfäden Sarah Hoffmann

Hoi Sven,

On Fri, May 04, 2012 at 11:33:28AM +, Sven Geggus wrote:
 hike39 ho...@hike.de wrote:
 
  nachdem auf diese Fragestellung sich niemand von den osm.de Machern
  angesprochen gefühlt hat, möchte ich diese Frage irgendjemanden aus
  dieser Truppe zukommen lassen. 
 
 Was soll das jetzt? Ich habe die Nominatim Suche auf osm.de
 postwendend dem Vorschlag von Sarah angepasst, das ist auf dieser
 Liste nachzulesen!

Ich denke es geht hier darum, zusätzlich beim Suchergebnis
anzuzeigen, welcher Art das Objekt ist (Stadt, Strasse, Haltestelle,
etc.) Dafür müsste man class und type auswerten, dass mit der
Antwort zurückkommt. Oder aber einfach das Icon anzeigen, dass
in der Antwort mitgeschickt wird.

Ich würde ja einen Patch schicken, aber ich weiss nicht, ob der
Code der Seite irgendwo öffentlich ist.

Gruss

Sarah

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

Re: [Talk-de] Suche nach Elbufer, Bad Schandau

2012-04-22 Diskussionsfäden Sarah Hoffmann

Hi,

On Sun, Apr 22, 2012 at 02:32:45PM +0200, hike39 wrote:
 Du scheinst Dich mit der Nomatim-Suche gut auszukennen. Darum noch eine
 Zusatzfrage. Bei den Ergebnislisten von OSM.org ist auch immer ein
 Hinweis ob dies ein Knoten, Weg oder z.B. fälschlicherweise eine
 Almhütte ist. Bei OSM.de fehlen diese. Ich finde diese Zusatzinformation
 sehr hilfreich. Wie kann man bewerkstelligen, dass dies dort auch so
 angeführt wird?

Das ist eher eine Frage für die Macher von osm.de. Nominatim liefert den
Haupttag des Objektes in der Suchantwort zurück. Es ist dann Sache der
Website, das irgendwie darzustellen.

Gruss

Sarah

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

Re: [Talk-de] Suche nach Elbufer, Bad Schandau

Hi,

On Fri, Apr 20, 2012 at 07:47:02AM +0200, Ronnie Soak wrote:
 Oehm, wenn ich noch mal nachhaken duerfte:
 
 Im obigen Beispiel mit Fischmarkt, Erfurt war es osm.org, das mit
 Coburg einige hundert km daneben lag und osm.de, der sich nur im
 Nachbarkreis vertan hat.

Die Daten vorher waren von Dezember. Damals gab es auch den Ilm-Kreis
noch als place=region:
http://www.openstreetmap.org/browse/node/240085076/history

Da er inzwischen von BBO gelöscht wurde, ist jetzt eben Coburg der
nächste.

Um soetwas zu 'debuggen' ist übrigens die Nominatim-Seite selber recht
nützlich: http://nominatim.openstreetmap.org/

Wenn du dort nach 'Fischmarkt, Erfurt' suchst, erhältst du bei den
Suchresultaten jeweils einen Link zu den Details. Für den Fischmarkt
zum Beispiel:
http://nominatim.openstreetmap.org/details.php?place_id=116887509

Unter 'Address' kannst du sehen, welche OSM-Objekte Nominatim berücksichtigt
hat, um die Adresse zu erstellen. Die ausgegrauten sind Kandidaten, die er
gefunden, aber verworfen hat und die schwarzen diejenigen, die tatsächlich
in der Adresse angezeigt werden. Und dort findest du bei Coborg einen
Link zu dem schuldigen Place-Node.

 Das ist mit einem aktuellen Test uebrigens noch genauso (aber das kann auch
 an irgend welchem Caching liegen).

Einfach mal die Seite neu laden (Ctrl+R), dann sollte es gehen.

Gruss

Sarah

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

Re: [Talk-de] Suche nach Elbufer, Bad Schandau

On Fri, Apr 20, 2012 at 09:03:52AM +0200, aighes wrote:
 Hallo,
 sollte Nominatim nicht erkennen: Erfurt ist admin_level=6, also kreisfrei?

Wie gesagt, normalerweise nimmt Nominatim an, dass zu admin_level=6
ein place=county gehört. place=region wird eine Stufe höher angesiedelt,
admin_level=5. Deshalb kommt beides in die Adresse: Erfurt als
Kreis und Coburg quasi als Regierungsbezirk (nicht, dass wir sowas
in Thüringen hätten, aber das weiss Nominatim nun mal nicht).

Man könnte natürlich für Deutschland eine Ausnahme einbauen, aber
erstens sind place=region als Kreis eher am Aussterben und zweitens
relativ inkonsitent verwendet.

Es gibt Kreise mit place=county in der DB:
http://www.openstreetmap.org/browse/node/240033539

und place=region-Nodes, die keine Kreise sind:
http://www.openstreetmap.org/browse/node/310541181
http://www.openstreetmap.org/browse/node/240092615
http://www.openstreetmap.org/browse/node/161555825
http://www.openstreetmap.org/browse/node/428230346

Ausnahmen würden also nur zu anderen Fehlern führen.

Gruss

Sarah

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

Re: [Talk-de] Suche nach Elbufer, Bad Schandau

On Fri, Apr 20, 2012 at 09:53:58AM +0200, hike39 wrote:
 
 
 Am 19.04.2012 17:59, schrieb Sven Geggus:
  Jimmy_K jimm...@gmx.at wrote:
  
  Meine Suche stammt von openstreetmap.org, aber auch openstreetmap.de 
  liefert bei mir keinen Aldi.
 
 
 Ich habe gerade nochmals nachgetestet. Bei der Suche über
 openstreetmap.de erhalte ich bei dem Suchmuster elbufer, bad schandau:

Mit Ctrl-R (oder Ctrl-F5) ein Neuladen der Seite erzwingen.

 bei www.openstreetmap.org das Ergebnis von nomatim, allerdings wird das
 Chalet als Almhütte bezeichnet, obwohl es mit tourism=chalet getagt ist.

Das haben die Übersetzer der Hauptseite so eingetragen. Wer die Übersetzungen
verbessern will, kann sich im TranslateWiki anmelden und dort
beitragen:

http://translatewiki.net/wiki/Translating:OpenStreetMap

Gruss

Sarah

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

Re: [Talk-de] Suche nach Elbufer, Bad Schandau

On Fri, Apr 20, 2012 at 10:45:35AM +0200, hike39 wrote:
 Werde mich da einmal einarbeiten. Aber ich habe auch im Wiki bei
 DE:Howto_Map_A nachgesehen, wie man Ferienwohnungen tagt. Dort ist für
 die Almhütte tourism=alpine_hut empfohlen.

Ja, die übersetzung Almhütte für chalet ist doch sehr irreführend.
(Um nicht zu sagen, falsch.)

 Aber dennoch eine andere Frage: Woher kommt eigentlich im dritten
 Treffer der Hinweis auf die Kirschleite. Das ist doch nur ein Fußpfad
 nördlich bzw Wege in der Nähe von bewusstem Objekt.

Das war der nächste highway=* zu dem Haus, vermutlich nur mit ein
paar Metern unterschied, aber das reicht. Nominatim macht keinen
unterschied ob Strasse oder Fusspfad. Wenn du das addr:street
in Am Elbufer änderst, sollte er es der richtigen Strasse
zuordnen. (Strassenname und addr:street müssen exakt
übereinstimmen.)

Sarah

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

Re: [Talk-de] Admin-Levels und Place-Nodes (war: Suche nach Elbufer, Bad Schandau)