from:"marcus.wolschon"

On Tue, 1 Dec 2009 13:58:35 +0100, Martin Koppenhoefer
dieterdre...@gmail.com wrote:
 fine, but to me it seems it doesn't care for the viral aspects of our
 current license, that is: every derived work (derived from our data) must
 have the same license: cc-by-sa 2.0


A website is no derived work of a map presented in it.
It is not adding any data to the map or changing the map
itself in a significant way.

Merely including something is not relevant.
Just like Linux-Distributions containing non-free software
and lots of unaltered GPL-software.

Marcus

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

Re: [Talk-de] Navigationsprobleme an (Kleeblatt)-Autobahnkreuzen

On Tue, 1 Dec 2009 09:39:44 +0100, Martin Simon grenzde...@gmail.com
wrote:
 2) die parallelen Verbindungsstücke nur als motorway_link taggen ohne
 jegliche Autobahnzurodnung (ohne ref-tag), damit das Navi einen
 Abbiegevorgang erkennt.

 Entweder kein Ref-Tag oder das der Autobahn auf die der Link führt.
 
 Die parallel laufenden Stücke führen zu 2 Zielen:
 1.: die Autobahn, zu der sie parallel laufen
 2.: die Verbindung zur kreuzenden Autobahn, welche schon mit dem ref
 der kreuzenden Autobahn getaggt ist.


Stimmt*grübel*.

Das erste Stück führt aus der Autobahn heraus
= Ref der anderen Autobahn.
Das mittlere Stück führt in die Gegenrichtung der anderen
Autobahn und von der Hin-Richtung der anderen in die eigene
Autobahn
= kein Ref Tag, da es zu beiden führt
Das letzte Stück führt zurück auf die eigene Autobahn
= Ref der aktuellen Autobahn


auf diese Weise hat die Ausfahrt immer die Ref der Autobahn
auf die man fährt. Diese ist unterschiedlich zur aktuellen
und somit immer ein eindeutig erkennbarer Abbiege-Vorgang.

Sogar das rechts halten auf wärend man schon in der
Ausfahrt ist und die zweite Ausfahrt nehmen muss hat
hierbei eine Änderung der Ref von NULL in die der Ziel-Autobahn
was bei einfachen Algorithmen zu Jetzt rechts halten auf Autoahn2
führt.


Marcus



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

Re: [Talk-de] Navigationsprobleme an (Kleeblatt)-Autobahnkreuzen

On Tue, 1 Dec 2009 11:45:23 +0100, Bernd Wurst be...@bwurst.org wrote:
 Oder man macht es so wie es das Garmin in der Praxis macht:
 Erkenne dass _link eine Rampe ist und schaue in der eigenen
 Routen-Planung 
 weiter wann die nächste Nicht-Rampe kommt und gebe deren Bezeichnung
aus.


Dir ist klar dass hinter den highway=*_link 2 verschiedene
Autobahnen liegen? Ist der gut genug hierfür die berechnete
Route heraunzuziehen?
Ich habe nicht genug Wissen von Garmin im Speziellen und
nam das dümmste mögliche OSM-Navi an, damit eine Lösung auch
mit allen funktioniert und keiner speziell für Garmin tagged.

Marcus

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

Re: [Talk-de] Grundlegende Frage zum Datenaufbau

On Tue, 01 Dec 2009 12:46:38 +0100, Peter Körner osm-li...@mazdermind.de
wrote:
 [1] http://wiki.openstreetmap.org/wiki/OSM_Protocol_Version_0.5/DTD

Ich denke das wäre eher:
http://wiki.openstreetmap.org/wiki/OSM_Protocol_Version_0.6/DTD

und zusätzliche Elemente bei JOSM:
http://wiki.openstreetmap.org/wiki/JOSM_file_format


Marcus

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

Re: [Talk-de] OSM Inspector jetzt weltweit und mit places-Ansicht

On Tue, 01 Dec 2009 15:02:24 +0100, Frederik Ramm frede...@remote.org
wrote:
 Zum detaillierten englischen Announcement im Geofabrik-Blog: 
 http://blog.geofabrik.de/?p=27


Sehr nützliches Werkzeug.
Cool! :)


Marcus

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

Re: [Talk-de] OSM Inspector jetzt weltweit und mit places-Ansicht

On Tue, 01 Dec 2009 15:02:24 +0100, Frederik Ramm frede...@remote.org
wrote:
 Hallo,
 
 der Geofabrik-OSM-Inspector (tools.geofabrik.de/osmi) bietet jetzt 
 einige wichtige Fehlerkorrektur-Views weltweit (mit täglichen Updates) 
 an. Ausserdem gibt es einen ganz neuen places-Layer, der Ortschaften 
 und ihre Größe anzeigt, sowie (speziell für die Mapper in den 
 Niederlanden) eine AND-Ansicht.
 
 Zum detaillierten englischen Announcement im Geofabrik-Blog: 
 http://blog.geofabrik.de/?p=27
 
 Bye
 Frederik



Hallo Frederik,

was wäre nötig um zusätzliche Checks hinzuzufügen?
Ich denke da an das Zusammenspiel von Node und
Polygon/Multipolygon oder das zeichnen eines geschätzten
Umkreises wenn nur ein Node da ist (so dass man sieht
wo man was zeichnen müsste weil so eine Schätzung nach
den Radien aus dem Wiki komplett daneben liegen würde).

Gruss,
Marcus

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

Re: [Talk-de] Navigationsprobleme an (Kleeblatt)-Autobahnkreuzen

2009-11-30 Thread marcus.wolschon

On Sat, 28 Nov 2009 18:04:06 +0100, Ana Luisa Paldos Garcia
analuisapaldosgar...@googlemail.com wrote:
 Die Frage nun .. was tun:
 
 1) davon ausgehen, dass das Problem bei der Navigationssoftware liegt und
 auch dort gelöst wird

Nicht davon ausgehen sondern einen Bug-Report mit allen Details schreiben.

 2) die parallelen Verbindungsstücke nur als motorway_link taggen ohne
 jegliche Autobahnzurodnung (ohne ref-tag), damit das Navi einen
 Abbiegevorgang erkennt.

Entweder kein Ref-Tag oder das der Autobahn auf die der Link führt.

 3) ...


Marcus

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

Re: [OSM-talk] Mapping everything as areas

2009-11-25 Thread marcus.wolschon

On Wed, 25 Nov 2009 14:11:29 +0100, Jean-Marc Liotier j...@liotier.org
wrote:
 Ævar Arnfjörð Bjarmason's diary entry last week (http://j.mp/8ESP8o) 
 stired my interest. Using a few examples, he showed how mapping 
 everything as an area - or as a volume - makes ultimate sense. Should we 
 go for it now ?

Not really.
At least not this or next year.

That is the realm of city-planing where you need to know
the number of stones to pave a sidewalk.
We have a road-map. And...btw..nowhere near the accuracy
required to map the width of sidewalks, space between sidewalk
and road,...

Marcus

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

[Talk-de] B517




http://www.openstreetmap.org/?lat=50.147085lon=8.460473zoom=18
vs
http://maps.google.de/maps?f=qsource=s_qhl=deq=B517,+Nordrhein-Westfalensll=50.140331,8.468485sspn=0.041147,0.111494ie=UTF8cd=1geocode=FcgLCwMdKFl6AAsplit=0hq=hnear=B517,+Nordrhein-Westfalenll=50.98718,7.991867spn=0.040414,0.111494t=hz=14


Kann mir jemand mit Ortskenntniss sagen ob die B517 in Krombach aufhört
und ob die B54 nach Süden weiter geht oder nicht?

(Bin gerade dabei fehlende Relationen in
http://wiki.openstreetmap.org/index.php?title=WikiProject_Germany/Bundesstraßen
 nachzutragen. Hilfe ist willkommen.)

Gruss,
Marcus



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

Re: [Talk-de] Luftbilder mit Quadrocopter



300m sind erlaubt und damit kriegst du schon eine sehr grosse Menge.
Denke mal an kleine Ortschaften wo wir die 2 Durchgangs-Strassen
schon haben gegen die der Rest des Bildes rektifiziert werden kann.

Marcus



On Fri, 20 Nov 2009 09:51:18 +0100, Friedhelm Schmidt fschm...@extend.de
wrote:
 Hallo Markus,
 
 nach meinen Erfahrungen sollten Luftbilder für das Kartieren über
 bebautem Gebiet 
 mindestens aus 800 m Höhe (in der freien Landschaft gerne doppelt so
hoch)
 aufgenommen 
 sein. Sonst hast du einfach zu wenige Bezugspunkte für die
 Georeferenzierung.
 
 Beispiel: http://warper.geothings.net/maps/warp/810
 
 Das dürften etwa 800 m sein und wurde mit einer Canon IXUS 80
aufgenommen.
 
 Deshalb denke ich, Quadcopter, Drachen und sonstige Flugmodelle fallen
 für's Mappen aus.
 
 Grüßle
 
 -fri-
 
 ___
 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] B517

On Fri, 20 Nov 2009 10:30:32 +0100, Andre Joost
andre+jo...@nurfuerspam.de
wrote:
 marcus.wolsc...@googlemail.com schrieb:

 http://www.openstreetmap.org/?lat=50.147085lon=8.460473zoom=18
 vs

http://maps.google.de/maps?f=qsource=s_qhl=deq=B517,+Nordrhein-Westfalensll=50.140331,8.468485sspn=0.041147,0.111494ie=UTF8cd=1geocode=FcgLCwMdKFl6AAsplit=0hq=hnear=B517,+Nordrhein-Westfalenll=50.98718,7.991867spn=0.040414,0.111494t=hz=14


 Kann mir jemand mit Ortskenntniss sagen ob die B517 in Krombach aufhört
 und ob die B54 nach Süden weiter geht oder nicht?


   
 http://de.wikipedia.org/wiki/Bundesstra%C3%9Fe_517

http://www.derwesten.de/nachrichten/staedte/kreuztal/2009/3/3/news-113258451/detail.html
 
 kennst du?


Zum Jahresbeginn 2009 wurde die B 517 um ein 6 km langes Teilstück der
alten B 54 zwischen Kreuztal-Krombach und Kreuztal Mitte verlängert.[1]

Okay. Also ist unsere B517 korrekt und sehr aktuell.
Danke

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

Re: [Talk-de] Handy für OSM

On Fri, 20 Nov 2009 11:18:40 +0100, Peter Körner osm-li...@mazdermind.de
wrote:
 Dieter Jasper schrieb:
 Hallo Liste,
 da ich nun als bisher Handy-Vereigerer ein Handy brauche, hätte ich 
 gerne Info über Handys ,die auch gut für OSM geeignet sind:
 
 
 Wie wäre es mit einem iPhone? MotionX GPS als
 Tracker, Fotos sind automatisch Georeferenziert und ein Voice Recorder 
 liegt auch bei.

Beliebiges Windows-Mobile Handy mit GPS und/oder Bluetooth(für externes,
genaueres GPS).
Optional mit Kamera.

OSMtracker ist GEIL!


Marcus

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

Re: [Talk-de] Luftbilder mit Quadrocopter

On Fri, 20 Nov 2009 11:50:00 +0100, Friedhelm Schmidt fschm...@extend.de
wrote:
 marcus.wolschon schrieb:
 
 300m sind erlaubt und damit kriegst du schon eine sehr grosse Menge.
 Denke mal an kleine Ortschaften wo wir die 2 Durchgangs-Strassen
 schon haben gegen die der Rest des Bildes rektifiziert werden kann.
 
 Hast du das mal probiert, oder woher weißt du das?
 
 Hier ist ein Beispiel aus ca. 300 m  über Grund.
 
 http://www.bilder-upload.eu/upload/kazSiR7yF1y18Gx.JPG
 
 Wie du siehst, ist da fast nichts drauf. Nett wenn man die Details der
 Kreuzung mappen 
 will, aber sonst praktisch unbrauchbar.

Das ist doch Super.

All die Gebäudeumrisse, Parkplätze, Tennis-Plätze, Telephonzellen,...

Marcus

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

Re: [OSM-talk] NearMap and OpenAerialMap

2009-11-19 Thread marcus.wolschon

On Thu, 19 Nov 2009 11:19:57 +1000, morb@beagle.com.au wrote:
 Just a quick thought
 
 I just realised that NearMap is doing most of the job of the
OpenAerialMap
 concept. I wonder if there is some scope to combine the efforts?

http://www.nearmap.com/community/contribute.aspx
Contrary to OpenAerialMap I find no mention of any way
to upload your own aerial photos at all.

Marcus

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

Re: [Talk-de] HighPrecision GPS receiver home build?

2009-11-18 Thread marcus.wolschon

On Wed, 18 Nov 2009 12:14:20 +0100, Frank Sautter
openstreet...@sautter.com wrote:
 Johann H. Addicks schrieb:
 Irgendwie klingt das nach Schlangenöl:

http://hacknmod.com/hack/diy-real-time-gps-receiver-with-incredible-accuracy/
 
 da ist aber was dran. hier ist die eigentliche projektseite
 http://gpspp.sakura.ne.jp/rtklib/rtklib_beagleboard.htm
 
 bei beagleboard hat es das projekt auf die homepage geschafft:
 http://beagleboard.org/
 
 und make schreibt auch etwas dazu
 http://blog.makezine.com/archive/2009/11/diy_real_time_kinematic_gps.html
 
 und wikipedia zu RTK
 http://en.wikipedia.org/wiki/Real_Time_Kinematic

Das Projekt und die Webseite gingen auch schon auf der Mailing-Liste
des Paparazzi Autopiloten rum.
Das Teil braucht einen zweiten Empfänger an einer EXAKT bekannten Positon
in der Nähe.
Bringt uns also nicht.

Marcus

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

[Talk-de] WikiProject_Germany/Bundesstraßen - Hi lfe gebraucht

2009-11-18 Thread marcus.wolschon

Hallo Leute,

ganz unten auf
http://wiki.openstreetmap.org/wiki/WikiProject_Germany/Bundesstra%C3%9Fen#B_400_.E2.80.93_B_449
gibt es noch eine Hand voll Bundesstrassen die noch keine
type=route
route=road
ref=B ???
name=B???

-Relation haben.
Wer erbarmt sich die mal in einer halben Stunde zusammenzuclicken?
Etliche weiter oben hab ich schon gemacht.

Ich würde gerne die Tage mal automatisch die TMC LocationCode
für Roads (wichtige Strassen) importieren, damit wir Staumeldungen
exakt und Spurgenau auf unsere Karte referenzieren können.
Dabei werden für Autobahnen und Bundesstrassen nur solche mit
einer entsprechenden Relation auch gefunden (sonst würde das
mit einem Späteren Import von TMC-Strassensegmenten, Punkten
und Kreuzungen kollidieren).

Vorgehen:

1) Auf einer anderen Karte nach B??? suchen.
2) Bei uns nach einem Ort in der Nähe suchen
3) Ein Segment der bereits bei uns existierenden Bundesstrasse in Potlatch
öffnen
4) Rechts den mittleren Button zu neuer Relation hinzufügen clicken
5) in der Reihenfolge wie die Strassen eben zusammenhängen bis zum anderen
Ende der Bundesstrasse die Teilwege so hinzufügen
6) Dann den Rückweg (falls das 2 Ways für 2 Rictungen sind)
7) save
8) nochmal auf eine der Strassen clicken, auf die Relaiton clicken und
die ID der Relation kopieren in die Webseite kopieren

PS:
einige Male hab ich ein note=Kraftfahrstrasse gefunden.
Bei solchen kann man gerne auch gleich motorroad=yes hinzufügen.
Schliesslich sind wir die einige Karte welche Kraftfahrstrassen
überhaupt mal erfasst und für Leute mit 50er-Rollern,... sind die
echt wichtig.

Marcus

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

Re: [Talk-de] Mehrere Hausnummern im Karlsruhe-Schema

2009-11-17 Thread marcus.wolschon

On Tue, 17 Nov 2009 12:30:10 +0100, André Riedel riedel.an...@gmail.com
wrote:
 Wir brauchen daher eine Möglichkeit, einem einzelnen Punkt oder
Gebäude
 eine Folge von Hausnummern zuzuweisen. Mir persönlich gefällt der
 Vorschlag [1] sehr gut: Es wird erlaubt, einem Konten eine Hausnummer
 wie addr:housenumber=3-7 zu geben. Dazu muß aber auch *an diesem
Knoten*
 ein addr:interpolation= festgelegt werden. Somit könnte man 3,4,5,6,7
 abbilden als:

 node id=1
  tag k=addr:housenumber v=3-7 /
  tag k=addr:interpolation v=all /
 /node

 Und das hier wäre 3,5,7:

 node id=1
  tag k=addr:housenumber v=3-7 /
  tag k=addr:interpolation v=odd /
 /node
 
 Finde ich eine sehr gute Lösung. Damit es dem bisherigen Schema nicht
 widerspricht, muss dieses jedoch um eine zusätzliche Auswertung
 ergänzt werden.
 - einfacher way: bisherige Adressinterpolation
 - geschlossener way oder node: einzelnes Gebäude mit mehreren
Hausnummern


Da es sehr viele Leute betrifft und das es ja noch genug Sonderfälle zu
Erschlagen gibt schlage ich mal vor das 
1)
sauber im Wiki als eigene Proposal-Seite
auszuformulieren incl. einer Erweiterung des eindeutigen Algorithmus für
die
Auswertung von Hausnummern (damit nicht jeder andere Annahmen macht wie das
wohl ausgewertet werden soll) und 
2)
auf der routing- und dev- Mailing-Liste mal die Leute zu fragen, die hier
die
Hausnummern für ihre Anwendungen auswerten.
3)
danach auf der internationalen Talk-Liste zur Abstimmung ankündigen.


Sonst doktorn wir da noch jahrelang an zig Erweiterungen des Schemas
rum.

Marcus

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

Re: [Talk-de] Kreisverkehr für Relationen aufspalten

2009-11-16 Thread marcus.wolschon

On Mon, 16 Nov 2009 10:25:14 +0100, Jan Tappenbeck o...@tappenbeck.net
wrote:
 Moin !
 
 ich bin gerade dabei Bedarfsumleitungen bei den Autobahnen zu 
 definierten und da Lübeck eine Vielzahl davon haben werden diese von 
 diesen Verläufen auch berührt.
 
 Nun stellt sich für mich die Frage - den ganzen Kreisel in die Ralation 
 aufnehmen, man kann ja auch mehrfach dadurch fahren (Scherz), oder 
 aufsplitten ?

Es sind Ways und sie sind Teil der Umleitung, also aufnehmen.

Ich prophezeihe mal einige Anwendungen die nicht korrekt mit
Kreisverkehren umgehen können die aus mehr als einem Way bestehen.
(Fahren sie in den Kreisverkehr, dritte Ausfahrt.) An den Fall
hatte ich zumindest nie gedacht.

Muss ich mal probiere welche Schwierigkeiten das macht.

Marcus

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

Re: [Talk-de] Plz / Orte mit Strassen

2009-11-16 Thread marcus.wolschon

On Tue, 17 Nov 2009 00:44:06 +0100, Karl Weber karl.webe...@gmx.net
wrote:
 Bei dieser Gelegenheit noch eine etwas abgleitende Frage: Ich habe schon
im
 
 August Hausnummern nach dem Karlsruher Schema erfasst, aber eben nur mit 
 addr:housenumber. OpenRouteService.org kennt diese Hausnummern immer noch

 nicht und positioniert den Standort immer nur irgendwie in der Mitte
der 
 Strasse. Liegt das vielleicht an meinem Vorgehen, i.e. sollte das
 prinzipiell 
 funktionieren?


Dein Vorgehen war auf jeden Fall schonmal korrekt.
Inwieweit ORS alle vorgesehenen Möglichkeiten der Zuordnung
von Hausnummer zu Strasse nutzen kann ist mir aber nicht bekannt.

Marcus

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

Re: [OSM-talk] Addressing Question

2009-11-13 Thread marcus.wolschon

On Thu, 12 Nov 2009 14:29:14 -0500, Anthony o...@inbox.org wrote:
 On Thu, Nov 12, 2009 at 9:14 AM, Andy Allan gravityst...@gmail.com
wrote:
 It's a fairly well established convention that in OSM it's the
 houses/plots, not the road centrelines, that are addressed.
 
 But that doesn't always reflect reality.  The reality, at least in
 many parts of the world, is that the streets are given blocks of
 potential addresses, and the houses/plots/whatever are given actual
 addresses from those potential address blocks.

So your point being?
These blocks can be interpolation-ways next to the way
and if you like relations you can have both grouped
in an associatedStreet-relation.

 I'd say it's better to approximate the gap between the road and the
 houses
 (10m?) than to just put it on the centreline due to that being easier.
 
 First of all, how would you approximate the gap?  You mean by hand?

10m along the normal of the road.

 Secondly, what if the houses aren't yet there?  Tiger address data
 represents *potential* address blocks, not *actual* address blocks.
 There may or may not be any actual houses along those roads.

Then we have to assume it's there until a mapper who can actually look
for houses can correct this. That's the best we can do.

Marcus

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

Re: [Talk-de] TMC LCL - erster, begrenzter Bot-Lauf

2009-11-13 Thread marcus.wolschon




Hallo,

ich habe begrenzt auf die Wiki-Seite
http://wiki.openstreetmap.org/wiki/TMC/TMC_Import_Germany/Areas/42000_to_42100
einen Bot laufen lassen, der die TMC-Tags auf einige der
Orte und Kreise automatisch setzen kann.

Könnt ihr mal durchsehen ob euch etwas auffällt, was
einem Lauf auf dem Rest der Areas entgegen stehen würde?

Von den 90 Regionen (Kreise und Gemeinden) hat er
* 4 automatisch zuordnen können
* von den anderen Regionen existierten die meisten halt bei uns noch nicht
* die 4 Dörfer Aulendorf,Renchen,Wolfach hatten nur ein
landuse=residential-Gebiet
  aus Landsat-Bildern. Die hätte er noch taggen können aber sowas hab ich
ihm
  lieber nicht erlaubt.

Immerhin, 4% weniger Arbeit für die TMC-Gebiete wäre etwas.
Der Gleiche Bot soll später bei den TMC-Roads in der Grössenordnung
von 50-90% der in TMC vorkommenden Strassen ihren Code als Tag zuordnen.
(Wieder mit jeder Menge Sanity-Checks. Besser dass er fast nichts zuordnet
 als dass er einen Fehler macht.)

Gruss,
Marcus

On Thu, 12 Nov 2009 21:28:49 +0100, Marcus Wolschon
marcus.wolsc...@googlemail.com wrote:
 My script for tagging a few of the areas automatically is done.
 
 I had it run on only one wiki-page this time:

http://wiki.openstreetmap.org/wiki/TMC/TMC_Import_Germany/Areas/42000_to_42100
 
 It found a few of the cities. No area it tagged seems to have been wrong,
 so it seems to be safe due to all the sanity.checks.
 
 It calculated an absurd bounding-box for
 http://www.openstreetmap.org/browse/relation/93594 (1.56-5.13 and
 1.66-5.08 instead of 47.83-47.9 and 7.67-7.767)
 I`ll have to investigate then. All the other bounding-boxes looked fine.
 
 Of the 90 areas it found 4 correctly. For most of the other ones we
 had no relation
 or polygon with that name.
 
 For 2 of them we had something with the correct name but in a
 different location,
 so these where ignored.
 
 For the villages of:
 * Aulendorf
 * Renchen
 * Wolfach
 there are only areas tagged landuse=residential, name=...
 taken from landsat images. I`m not sure if I shall assume them to be
 the best we have on such villages and simply tag them as being that
 village. I tend to like humans to do that and ignore these in the
program.
 
 What do you think of the result?
 Found anything wrong? non-ascii characters mangled, things it could have
 found
 with additional matching-rules or additional search-terms?
 
 Marcus

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

Re: [Talk-de] Plz / Orte mit Strassen

2009-11-12 Thread marcus.wolschon

On Thu, 12 Nov 2009 13:57:01 +0100, Hartmut Holzgraefe hart...@mysql.com
wrote:
 Garry wrote:
 
  Eingemeindungen heissen wohl nicht zwangsläufig dass sich auch die
  Postleitzahl ändert.
  Zumindest ist es bei deh Telefonvorwahlen so: bei uns gibt es trotz ca.
  35Jahre alter Eingemeindnung immer noch getrennte
  Vorwahlen.
 
 bei Telefonvorwahlen hängt es auch davon ab an welcher Vermittlungs-
 stelle man hängt, es gibt hier in Bielefeld mindestens eine Siedlung in
 der die Telefone die Gütersloher statt der Bielefelder Vorwahl haben ...

Und der Unterschied zu PLZ ist welcher?
Die PLZ hängt (wie der Name sagt) von der Post ab
und der sind Eingemeindungen ziemlich egal. Der
Briefkasten steht immer noch am gleichen Haus.

Marcus

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

Re: [Talk-de] Plz / Orte mit Strassen

On Wed, 11 Nov 2009 11:21:53 +0100, Auer, Thomas ta...@kues.de wrote:
 Hallo,
 
  
 
 ist jemand in der Lage, mir zu helfen, eine Datenbank zu erstellen mit
 allen Orten und dazugehörenden Straßen von Deutschland?
 
 Oder gibt es sowas schon ?

Orte und Strassen sind kein Problem.
Aber mit dem dazugehörige wirst du einiges
an Kopfzerbrechen haben.

Für Orte suche nach Nodes, Ways und Relationen
mit place=* und name=*.

Enthaltensein findest du hier:
http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing#City


Marcus

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

Re: [Talk-de] Plz / Orte mit Strassen

On Wed, 11 Nov 2009 11:51:15 +0100, Auer, Thomas ta...@kues.de wrote:
 Ja klar kann und will ich das sagen, wofür ich es brauche:
 Ich will die Datenbank in einer Software einsetzen um die Erfassung von
 deutschen Adressen zu vereinfachen. 
 Also so wie es heute jedes Navi kann, soll der Anwender in der
 Windows-Software nach Eingabe der Plz eine Liste mit Orte sehen und per
 Auto-Vervollständigung Orte tippen können und genauso dann mit den
 Strassennamen.
 
 Oder spricht (auch aus Lizenzrechtl. Sicht ?) etwas gegen diese Idee ?


In that case.
Feel free to use the existing:
http://sourceforge.net/apps/mediawiki/travelingsales/index.php?title=Plugin/AdvancedAddressDBPlaceFinder

It already creates such a database and does the searching including
a full implementation of the Karlsruhe Schema for house-numbers.
Ideas for enhancements and Patches welcome ;)


Marcus

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

Re: [Talk-de] Plz / Orte mit Strassen

On Wed, 11 Nov 2009 12:41:36 +0100, Bernd Wurst be...@bwurst.org wrote:

 Jede Hausnummer hat eine vollständige Adressangabe hinterlegt und so
erhält man immer eine 
 Zusammengehörigkeit von Ort, Straße und Haus.

Das ist schlichtweg falsch.
Fast alle haben nur addr:housenumber eignetragen.
Wo es nötig ist noch addr:street.


Marcus

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

Re: [Talk-de] Plz / Orte mit Strassen

On Wed, 11 Nov 2009 13:24:09 +0100, Bernd Wurst be...@bwurst.org wrote:
 Am Mittwoch 11 November 2009 12:54:37 schrieb
 marcus.wolsc...@googlemail.com:
 Das ist schlichtweg falsch.
 Fast alle haben nur addr:housenumber eignetragen.
 Wo es nötig ist noch addr:street.
 
 Du hast ne lustige Definition von fast alle und wo es nötig ist.
 
 Laut Tagwatch wird addr:housenumber momentan 469428 mal benutzt und
 addr:city 
 358528 mal. addr:street 436075 mal.

Auch auf den gleichen Nodes?
Ich kenn nur die Situation in diversen
Städten hier im Dreiländereck. Auf
Tagwatch hab ich wenig geschaut.

Marcus

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

Re: [Talk-de] Plz / Orte mit Strassen

On Wed, 11 Nov 2009 13:47:52 +0100, Sven Anders s...@anders-hamburg.de
wrote:
 Am 11.11.2009 13:36, schrieb Bernd Wurst:
 Am Mittwoch 11 November 2009 13:24:09 schrieb Bernd Wurst:
 Das heißt, weniger als 1/4 (dein fast alle) haben einen Ort

 Damn. Knapp 1/4 haben *keinen* Ort angegeben.
 
 Das macht nichts, wenn wir ein paar Anwendungen haben, bei denen diese 
 nicht gefunden werden, werden die schon früher oder später einen Ort 
 bekommen!


Ach so möchtest du das Erfassen von Hausnummern fördern.
Indem du die Latte noch höher setzt und unseren Freiwilligen
noch mehr Arbeit zumutest? Vor allem eine Arbeit die nicht
notwendig ist.
Ein Ort hat ein Gebiet in Form eines Polygons, Multipolygons
oder als Notlösung Kreis und alle Strasse darin gehören zum Ort. 

Marcus

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

Re: [Talk-de] Plz / Orte mit Strassen

On Wed, 11 Nov 2009 15:16:58 +0100, Sven Anders s...@anders-hamburg.de
wrote:
 Ist es denn wirklich so viel Arbeit? Ich erfasse in der Regel ganze 
 Straßen mit Hausnummern. Die Selektiere ich zum schluß einmal
 z.B. durch suchen nach addr:housnumber und setze dann für alle einmal 
 Straße, PLZ und Ort.

Woher hast du die ganzen Postleitzahlen?

Ich ziehe um alle Strassen des Ortes ein Polygon, benenne
das als place=village und name=XYZ und fertig. Damit weis ich,
dass ich keine der Häuser in diesem Ort jemals wieder anschauen
muss weil ja bei einem davon addr:city fehlen könnte.

 Wer es nicht macht, macht es halt nicht. Vielleicht gibt es ja auch 
 Tools die die Postleitzahl und Straße erraten können, kein Problem. 

Dieses erraten der Strasse ist Teil der Spezifikation des Karlsruhe
Schemas. Ob deine Postleitzahlen überhaupt korrekt sind wage ich mal
zu bezweifeln.

 Ein Ort hat ein Gebiet in Form eines Polygons, Multipolygons
 oder als Notlösung Kreis und alle Strasse darin gehören zum Ort.
 
 Wenn ich mir ansehe, wieviele Gemeindegrenzen noch fehlen, brauchen wir 
 über Orte nicht zu reden.

Wen interessieren schon Gemeindegrenzen. Die Tauchen in Adressen ja
nicht auf. Wenn ich einen Ort haben will suche ich nach Ortschaft,
Strasse, PLZ und Hausnummer, nicht nach Landkreis u.ä. .

 BTW: Ich hatte ja schon mal gefragt, wie wir ein Postleitzahlengebiet 
 taggen wollen. Da gab es aber noch keine einheitliche Vorgehensweise 
 (vermutlich ist es auch ziemlich egal wie die Lösung aussieht, aber wenn

 wir was einheitliches hätten, könnten wir auch dafür mal einen
Validator

Wenn eine ganze Ortschaft nur eine PLZ hat, tagge ich halt addr:postcode
mit an das Polygon.

Marcus

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

Re: [Talk-de] Problem mit aktueller Osmosis-Version.

On Tue, 10 Nov 2009 10:29:09 +0100, Kai Behncke kai-behn...@gmx.de
wrote:
 Hallo liebe Liste,
 
 Nachdem ich mit gerade auf Windows XP die neues Full-Version von
 http://dev.openstreetmap.org/~bretth/osmosis-build/osmosis-latest.zip
 
 heruntergeladen habe habe ich nun Schwierigkeiten dieses auszuführen
(eine
 alte Osmosis-Version war kein Problem).
 
 Es ist dabei egal ob ich E:/osmosis/ java -jar osmosis.jar oder mit der
 osmosis.bat aufrufe.
 
 Ich erhalte immer wieder:
 
 INFO: Osmosis Version 0.31
 10.11.2009 10:28:01 org.openstreetmap.osmosis.core.Osmosis main
 SCHWERWIEGEND: Execution aborted.
 java.lang.NoClassDefFoundError: org/java/plugin/PluginLifecycleException
 at org.openstreetmap.osmosis.core.Osmosis.run(Osmosis.java:73)
 at org.openstreetmap.osmosis.core.Osmosis.main(Osmosis.java:30)
 
 
 Auf Google wird das Problem auch schon teilweise genannt, leider habe ich
 noch keine richtige Lösung gefunden.

Die Klasse ist mit der jpf.jar hinzu gekommen.

Kannst du mal deine osmosis.bat schicken?
Ich denke da fehlt ein Eintrag im Classpath.

Marcus

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

Re: [Talk-de] Problem mit aktueller Osmosis-Version.

On Tue, 10 Nov 2009 11:38:09 +0100, Kai Behncke kai-behn...@gmx.de
wrote:
 Hallo Marcus,
 
 
 Die Klasse ist mit der jpf.jar hinzu gekommen.
 
 Kannst du mal deine osmosis.bat schicken?
 Ich denke da fehlt ein Eintrag im Classpath.
 
 Marcus
 
 ich habe eine Fehlermeldung bekommen, als ich Dir die osmosis.zip
geschickt
 habe (die Batch-Datei),
 Du kannst Diese aber auch herunterladen unter:
 
 http://www.selbstverwaltung-bundesweit.de/osmosis.zip (enthält nur die


ja, da fehlt die lib/test/jpf-1.5.jar in -cp 

Marcus

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

Re: [Talk-de] Problem mit aktueller Osmosis-Version.

On Tue, 10 Nov 2009 12:10:52 +0100, Kai Behncke kai-behn...@gmx.de
wrote:

%MYAPP_HOME%\osmosis.jar;%MYAPP_HOME\lib\test\jpf-1.5.jar;%MYAPP_HOME%\lib\commons-logging.jar;%MYAPP_HOME%\lib\mysql-connector-java-5.0.7-bin.jar;%MYAPP_HOME%\lib\postgresql-8.3-603.jdbc4.jar;%MYAPP_HOME%\lib\postgis_1.3.2.jar


You forgot one % after MYAPP_HOME


Marcus

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

Re: [Talk-de] Problem mit aktueller Osmosis-Version.

On Tue, 10 Nov 2009 12:44:27 +0100, Kai Behncke kai-behn...@gmx.de
wrote:
 java.lang.NoClassDefFoundError: org/apache/tools/bzip2/CBZip2InputStream

 Puh...could something else be missing maybe?

Without looking I guess there is a bzip2.jar still missing in the
classpath.
You know the drill...

Marcus

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

Re: [Talk-de] Orts/Straßennamen zu Koordinaten finden


Ich arbeite selber gerade an reverse Geocoding mit OSM.
Allerdings mit höheren Ansprüchen an die Qualität des
Ergebnisses als die Ad-Hoc SQL-Scripte hier.
Wird sich noch zeigen wie gut das Resultat dann am Ende
wird. Dauert alles noch.


 Das mit der geografischen zuordnung zu einem Place oder City wird
schon
 schwieriger - Eine eindeutige zuordnung geht nur ueber die boundary
 relations alles
 andere ist professionelles raten
 
 Mit ein bischen vorbereiten der boundary relations als geometrien in
einer
 datenbank geht das dann auch so:
 
 select  cb.id, cb.adminlevel, cb.name
 fromcompleteborders cb,
 (select ST_SetSRID(ST_Makepoint(8.1, 51.0), 4326) as pos) pos
 where   ST_Within(pos.pos, cb.border)
 order by adminlevel desc;
 
id   | adminlevel |name 
 ++-
  163253 |  8 | Hilchenbach
   62761 |  4 | Nordrhein-Westfalen
 (2 rows)
 
 Time: 38.139 ms

Nur das für die überaus meisten Ortschaften keine solche Relation
existiert
sonder maximal ein Polygon(way) und meist nur ein node.
Weiterhin: Wäre das Ergebniss der Auswertung der Relation nicht ein
Multipolygon statt einem Polygon?

 
 Das generieren der vordefinierten polygone aus den boundary relations
habe
 ich schonmal
 hier geschrieben:
 
 http://lists.openstreetmap.org/pipermail/talk-de/2009-October/056253.html

Dein Ansatz ignoriert vollkommen die Rollen-Tags.

Leider spezifiziert
http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative
so überhaupt garnichts ordentlich. Vor allem hinsichtlich dem gewünschten
Inhalt von Relationen.


 Das ganze oben ist natuerlich zu einfach - Es ist nicht garantiert das
die
 naechstliegende Straße noch in Hilchenbach ist .. D.h. eigentlich
muesste
 man 
 erst das polygon suchen und dann die Straße suchen und zu distance noch
 pruefen
 ob die Straße auch durch das Polygon laeuft ... Aber das sind details
die
 im ersten wurf mal zu vernachlaessigen sind ...


Das kommt noch alles dazu.

Und jetzt noch das Chaos mit den PLZ dazu...

Marcus

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

Re: [Talk-de] JOSM Relation Mitglieder sortieren

On Thu, 29 Oct 2009 12:03:10 +0100, Dimitri Junker o...@dimitri-junker.de
wrote:
 Hallo,
 
 die Möglichkeit mit JOSM die Relationmitglieder automatisch zu sortieren
 ist 
 ja toll, aber entweder hab ich es falsch verstanden oder da ist ein Bug
 drin.
 Soweit ich es kapiert habe soll der 1. Weg der Relation nicht verschoben 
 werden, so kann man also den 1. per Hand auswählen und dann sortieren.
Bei
 
 meinen Versuchen wurde aber regelmäßig der 1. verschoben. - Oft wurde
es
 
 anders herum sortiert als ich es wollte.
 Da es recht viel Klickerei ist einen Weg an den Anfang zu schieben würde
 ich 
 mir sowieso folgendes Vorgehen wünschen: Man selektiert den 1. Weg (egal
 wo 
 er steht) und klickt dann auf Sortieren. Außerdem fehlt ein
 Rückgängig. 


Du könntest einfach 2 Pfeil-Buttons v und ^ einbauen.
Sollte schnell gemacht sein.

Marcus

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

Re: [Talk-de] Einfache serverbasierte Routingsoftware?

On Thu, 29 Oct 2009 10:18:35 +0100, Frederik Ramm frede...@remote.org
wrote:
 Hallo,
 
 Sven Geggus wrote:
 Mal ganz von OSM abgesehen gibt es eigentlich keine generische
 Softwarebibliothek, die mir einfach nur den kürzesten Weg in einem Netz
 ausrechnet. Vielleicht sollte man mal schaun ob man da SPICE
missbrauchen
 kann :)
 
 Ich hoere immer, es gebe eine boost graph-Library, mit der sowas 
 moeglich waere. Hab ich aber noch nie probiert.

boost ist eine sehr umfangreiche Bibliothek mit allgemeinen
Graphen-Algorithmen.
Nur muss man für die erstmal einen Treiber schreiben mit dem sie
ihren Graphen von einer Datenbank wie unsrem PostGIS-Schema lesen kann.


Marcus

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

Re: [Talk-de] Orts/Straßennamen zu Koordinaten finden

On Thu, 29 Oct 2009 12:35:37 +0100, Florian Lohoff f...@rfc822.org wrote:
 On Thu, Oct 29, 2009 at 11:54:37AM +0100, marcus.wolsc...@googlemail.com
 wrote:
 
 Ich arbeite selber gerade an reverse Geocoding mit OSM.
 Allerdings mit höheren Ansprüchen an die Qualität des
 Ergebnisses als die Ad-Hoc SQL-Scripte hier.
 Wird sich noch zeigen wie gut das Resultat dann am Ende
 wird. Dauert alles noch.
 
 
 Was kannst du da besser machen? Die SQL Scripte geben exakte resultate
 d.h. nach spatialen kriterien. 

Die Daten vorher passend massieren.
* PLZ -Suche ermöglichen 
* In Tags angegebene Länder, Orte, PLZ, ... beachten.
* Multipolygone beachten.
* Verschiedene Tag-Schreibweisen und alternativ verwendete Tags.
* Die ganze Hausnummern-Zuordnung incl. Interpolation.

 Und nachdenken muss jeder der sowas macht ... Die anforderung
 bestimmt das ergebniss ...
 
 Und du kannst ja mal deine generische behauptung untermauern mit fakten
 oder
 meinungen - Das alles scheisse ist weiss ich - erzaehle ich auch jedem
der
 es
 nicht hoeren moechte ...

Hab ich das behauptet?
Ich lese nur dass ich recht hohe Ansprüche an die
Korrektheit des Ergebnisses stelle. Eine Anforderung
die nicht überall nötig ist.

Marcus

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

Re: [Talk-de] Orts/Straßennamen zu Koordinaten finden

On Thu, 29 Oct 2009 13:05:45 +0100, Florian Lohoff f...@rfc822.org wrote:
 Damit bezweifelst du dir korrektheit der SQL Statements - hast du
 dafuer belege? Das oben ist nur zusaetzliche information aber nichts
 was mit korrektheit zu tun hat.

Sie sind insofern nicht korrekt, dass die durchaus möglicher Rolle
inner z.B. nicht beachtet wird und wege in anderen Rollen als
 und outer nicht ignoriert werden. 
z.B. dürfte jeder eine Referenz
mit einer neuen Rolle part_of auf das Polygon eines umgebenden Gebietes
einbauen oder Partnerstadt auf das Polygon einer anderen Ortschaft
und solche Spässe. Darf ja jeder machen wie er will da so eine Rolle
noch nicht mit einer anderen Semantik benutzt wird oder dokumentiert ist.

 Und bei deiner Tag-Schreibweisen bin ich ja ein erklaerter gegner.
 Derjeniger moechte das die Daten funktionieren soll die Tags richtig
 schreiben und nicht allen die die daten verarbeiten aufzwingen
 megabyte an alternativschreibweisenlisten zu pflegen.

addr:postcode ist genauso richtig wie postal_code.
is_in:country ist genauso richtig wie addr:country
...

Marcus

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

Re: [Talk-de] Orts/Straßennamen zu Koordinaten finden

On Thu, 29 Oct 2009 13:11:54 +0100, Satz Klauer satzkla...@googlemail.com
wrote:
 Nana, nicht gleich streiten! Das war ja nun wirklich eine eher
 harmlose Frage - was macht ihr bei einer Diskussion Windows vs. Linux
 oder Java vs. C#? ;-)
 
 On 10/29/09, marcus.wolsc...@googlemail.com
 marcus.wolsc...@googlemail.com wrote:

 Ich arbeite selber gerade an reverse Geocoding mit OSM.
 
 Klingt gut - wird es Open Source?


Unwarscheinlich aber einige Ideen, die mir so gekommen sind, kann
ich für die  beiden alternativen Vorwärts-Adresssuchen in Traveling
Salesman gut verwenden.

Marcus

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

Re: [Talk-de] Einfache serverbasierte Routingsoftware?

On Thu, 29 Oct 2009 14:12:31 +0100, Tobias Wendorff
tobias.wendo...@uni-dortmund.de wrote:
 Gary G: schrieb:
 http://svn.openstreetmap.org/applications/utils/gary68/distancemap.pl
 
 an. im grunde leistet das programm das, was du möchtest. man müsste es
 ein wenig umschreiben, dass es z.b. parameter akzeptiert. und der weg
 müsste noch zusammengesetzt werden. implementiert ist der dijkstra
 algorithmus.
 
 Problem dürfte jedoch sein, dass der Graph ansich nicht
 gespeichert wird und bei jeder Abfrage neu aufgebaut
 werden müsste.
 
 Oder kannst Du den Graphen in eine Datei oder in den RAM
 schreiben?

Du scheinst von der Annahme auszugehen, dass der komplette Graph 
überhaupt gespeichert irgendwie speziell erstellte werden muss.
Sowas geht wunderbar für jeden gerade benötigten Teil on the fly.
(Man kann z.B. auch wunderbar mit unendlich grossen Graphen rechnen.)

Marcus

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

Re: [Talk-de] Orts/Straßennamen zu Koordinaten finden

On Thu, 29 Oct 2009 15:20:52 +0100, Florian Lohoff f...@rfc822.org wrote:
 On Thu, Oct 29, 2009 at 03:17:09PM +0100, marcus.wolsc...@googlemail.com
 wrote:
 On Thu, 29 Oct 2009 13:05:45 +0100, Florian Lohoff f...@rfc822.org
 wrote:
  Damit bezweifelst du dir korrektheit der SQL Statements - hast du
  dafuer belege? Das oben ist nur zusaetzliche information aber nichts
  was mit korrektheit zu tun hat.
 
 Sie sind insofern nicht korrekt, dass die durchaus möglicher Rolle
 inner z.B. nicht beachtet wird und wege in anderen Rollen als
  und outer nicht ignoriert werden. 
 
 Wieviele admin boundarys mit enclaven oder exclaven haben wir denn in D?
 Und wieviel
 der prozentualen flaeche macht das aus?

a)
Ich beschränke mich nicht auf D. Warum nimmst du das an?
b)
Ganze Länder sind selber ein admin-boundary mit Exclaven und Enclaven.
Wie viel mehr Fläche hättest du gerne?
Alles admin_boundary sind ja gleich zu verarbeiten. Egal was in admin_level
steht.
Also behandelst du ein paar gültige Fälle halt nicht.
Das macht in 99% keine Probleme und man kann es als Design-Entscheidung
problemlos akzeptieren. Muss man aber nicht.

 z.B. dürfte jeder eine Referenz
 mit einer neuen Rolle part_of auf das Polygon eines umgebenden
Gebietes
 einbauen oder Partnerstadt auf das Polygon einer anderen Ortschaft
 und solche Spässe. Darf ja jeder machen wie er will da so eine Rolle
 noch nicht mit einer anderen Semantik benutzt wird oder dokumentiert
 ist.Q
 
 Das problem ist alleine das in D wir mal alles ganz anders machen als
alle
 anderen - type=multipolygon hat international nichts mit grenzen zu tun -
 Nur
 in D ...

Es ist trivial zu unterstützen also kann man's auch gleich universell
machen. Multipolygon ist neben Polygon ja einer der Standard-Datentypen
in der GIS-Erweiterung.
Wenn wir es in D anders machen als woanders, dann muss eine Suche halt
mit Deutschland und mit dem Rest der Welt umgehen können ohne Fehler zu
machen.

  Und bei deiner Tag-Schreibweisen bin ich ja ein erklaerter gegner.
  Derjeniger moechte das die Daten funktionieren soll die Tags richtig
  schreiben und nicht allen die die daten verarbeiten aufzwingen
  megabyte an alternativschreibweisenlisten zu pflegen.

Verschiedene Philosophien.
Du verweigerst ein korrektes Ergebniss und willst so Mapper zwingen
korrekt zu mappen. Dabei unterstelle ich dir mal dass du annimmst,
derjenige welcher die Suche benutzt ist überhaupt Mapper.
Ich will das akurateste mögliche Ergebniss mit dem was momentan
so tatsächlich getagged ist. Das umfasst auch sehr oft benutzte, alte
Tags welche nützliche Informationen enthalten. (wie z.B. postal_code)

 addr:postcode ist genauso richtig wie postal_code.
 is_in:country ist genauso richtig wie addr:country
 
 Wofuer brauche ich die in dem obigen Beispiel?

Du brauchst sie, weil PLZ, Land und Hausnummer untrennbar zur Adresse
gehören.
Und jetzt lass mal das Rumgetrolle. Das ich nach mehr als nur Strasse+Ort
suche ist dir ja jetzt ausreichend bekannt.

Marcus


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

Re: [Talk-de] Einfache serverbasierte Routingsoftware?

On Thu, 29 Oct 2009 15:55:44 +0100, Tobias Wendorff
tobias.wendo...@uni-dortmund.de wrote:
 marcus.wolsc...@googlemail.com schrieb:
 Du scheinst von der Annahme auszugehen, dass der komplette Graph 
 überhaupt gespeichert irgendwie speziell erstellte werden muss.
 Sowas geht wunderbar für jeden gerade benötigten Teil on the fly.
 (Man kann z.B. auch wunderbar mit unendlich grossen Graphen rechnen.)
 
 Kannst Du das bitte in Deine Routingsoftware integrieren?
 Ich wollte neulich nur Dortmund reinladen, brauche aber auf
 einem aktuellen Standard-PC (2x 2.6 GHz, 4 GHz Arbeitsspeicher)
 mehrere Stunden - unter Linux und Windows.

Was hat das dynamische erstellen eines Graphen für eine Bibliothek
von Graphen-Algorithmen mit dem Import in ein anderes Dateiformat
(osmbin) von einem Navi zu tun?
Ich benutze diese Graphen-Bibliothek garnicht.

PS:
Probiere mal die SVN-Version. die benutzt die H2-Datenbank und
der Import ist wesentlich schneller als Osmbin. Sobald kein
Memory-Mapped IO mehr möglich ist wird der Dateizugriff auf
Binärdaten im Osmbin -format im Import zu langsam durch das
Aufbauen der Indize. Lesen ist rasend schnell (er muss ja
interaktiv ganze Städte rendern können wärend sich das Auto
bewegt) aber der Import war da schon immer der Pferdefuss.

Mit der H2-Datenbank als Alternative ist das Lesen kaum langsamer
aber der Import massiv schneller.

Wer eine EMBEDED Datenbank kennt die ohne Installation
ordentlich 2D-Daten indizieren kann, immer her damit.

Marcus

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

Re: [Talk-de] Algorithmus für effiziente PLZ-Gebiete g esucht

2009-10-28 Thread marcus.wolschon

On Wed, 28 Oct 2009 10:09:07 +0100, Jochen Topf joc...@remote.org wrote:
 Ich hab das mit Voronoi mal gemacht. Für die Statistik-Sprache R gibts
da
 Code.
 Und für PostGIS gibts ein R-Plugin. Anleitung dazu gibts irgendwo im
Web.
 Grundsätzlich kommen, wenn zumindest ein paar Punkte mit PLZ vorhanden
 sind,
 garnicht so schlechte Ergebnisse raus. Aber das ganze ist ziemlich
langsam.
 Eine einzelne Stadt bekommt man noch hin, aber für ganz Deutschland
würde
 es wohl Tage lang rechnen. Vielleicht kann man vorher die Punktmenge
 irgendwie
 ausdünnen oder so.

War das langsamer das Errechnen und speichern eines Voronoi-Diagramms oder
die Abfrage eines nearest neighbor?

Marcus

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

Re: [Talk-de] Einfache serverbasierte Routingsoftware?

2009-10-28 Thread marcus.wolschon

On Wed, 28 Oct 2009 10:45:35 + (UTC), Sven Geggus
li...@fuchsschwanzdomain.de wrote:
 Was ich brauche ist kurz gesagt folgendes:
 
 Input:Zwei Nodes
   (NA und NB)
 Output:   Verlauf von A nach B über OSM Wege (highway=*) egal welchen Typs

   (NA N1,N2 mit N2 = nächster Punkt zu NB)
..
 
 Hat damit schon mal jemand gearbeitet oder habt ihr
Alternativvorschläge?

http://sourceforge.net/apps/mediawiki/travelingsales/index.php?title=Traveling_Salesman#How_do_I_start.3F

Nur so eine Idee.
Ist halt mächtiger. Ich kann dir gerne auch Komandozeilen-Zugriff auf
z.B. die Adress-Suche einbauen.

Marcus

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

Re: [Talk-de] Einfache serverbasierte Routingsoftware?

2009-10-28 Thread marcus.wolschon

On Wed, 28 Oct 2009 12:30:46 +0100, Rotbarsch r...@gmx-topmail.de wrote:
 Hallo Sven!
 
 Kennst Du schon YOURS?
 
 http://www.yournavigation.org/about.html:
 
 Use YOURS as the routing engine in your application
 
 The routing API is OpenSource and open to 3rd party applications. This  
 means that you can either implement a copy of the routing API or use  
 this website as the routing backend for your application. See the wiki  
 link below for more information.
 
 http://wiki.openstreetmap.org/index.php/YOURS

Is there some way to get the OSM Node-IDs of a returned route?
Then I could write another IRouter-Implementation for Traveling
Salesman to choose from that uses YOURS. (e.g. for comparing routes
and for calculating routes of areas that are not even in the local
map.) It would have to ignore the IMetric chosen but it would work.

I guess it's not possible to have more then one target-locations?
(e.g. for routing to the nearest toilet or to any point on a given 
 way.)

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

Re: [Talk-de] Algorithmus fÃ¼r effiziente PLZ-Geb iete gesucht

2009-10-27 Thread marcus.wolschon

On Tue, 27 Oct 2009 13:19:24 +0100, Tobias Wendorff
tobias.wendo...@uni-dortmund.de wrote:
 Marcus Wolschon schrieb:
 An Voronoi-Diagramme hab ich schon gedacht. Mittels des Divide and
 Conquer -Ansatzes sollte das gut zu parallelisieren sein. Nur wie macht
 man das ohne einen großteil aller Punkte welche eine PLZ haben mehrfach
 in den Speicher zu laden oder gleich nochmal Speicher in der
 Größenordnung
 dieser Punktmenge zu benötigen?
 
 Die Bonner Geoinformatiker können vielleicht helfen:

http://www.ikg.uni-bonn.de/vorlesungsarchiv/Diskrete_Mathematik_II/Folien/neuefolien_bmbf/druck1/matheII_6_druck1.pdf


Wie Voronoi-Diagramme gemeinhin konstruiert werden habe ich wie jeder
Dipl.Inf gelernt. Momentan bevorzuge ich den Weg einfach alle Punkte die
eine PLZ
im richtigen Staat haben zu sammeln und zu dem abgefragten Punkt
einfach den mit geringster Entfernung von PostGIS heraus suchen
zu lassen.
Ist garnicht nötig wie Polygone im Vorfeld zu berechnen. Schliesslich
werden sie nie als solche angezeigt.

Gruss,
Marcus

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

Re: [Talk-de] Algorithmus fuer effiziente PLZ-Gebiete gesucht

2009-10-27 Thread marcus.wolschon

On Tue, 27 Oct 2009 15:17:11 +0100, Tobias Wendorff
tobias.wendo...@uni-dortmund.de wrote:
 marcus.wolsc...@googlemail.com schrieb:
 Ist garnicht nötig wie Polygone im Vorfeld zu berechnen. Schliesslich
 werden sie nie als solche angezeigt.
 
 Wieso eigentlich nicht? Ich würde das zum Debuggung sehr sinnvoll
 finden.
 
 So könnte man die Daten nämlich auch mit anderen Karten überlagern
 und Fehler finden. Solange man die anderen Daten nicht übernimmt,
 ist es okay.
 
 Könntest Du es dahingehend erweitern oder wäre es zu umständlich?

Die Implementierung ist inhouse und ich denke mal es reicht zum Debugging
dass man die volle Kontrolle über den Inhalt der Datenbank hat und
beliebige Punkte testen kann.
Den Rest einer potentiellen Fehlersuche kann man mit SQL erschlagen.

Marcus

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

[Talk-de] Algorithmus für effiziente PLZ-Gebiete g esucht

2009-10-26 Thread marcus.wolschon


Hallo Leute,

ich suche gerade eine geeignete Möglichkeit um eine
Lat+Lon - PLZ Abbildung zu machen.

Momentan denke ich darüber nach disjunkte, konvexe
Hüllen über alle Elemente welche innerhalb eines Staates
den gleichen Wert in addr:postcode bzw postal_code haben
zu bilden.
Dann könnte man über diese Polygone eine sehr, sehr grosse
Anzahl an Positionen ihren PLZ-Werten zuordnen.

Meine erste Idee wäre:

für alle (Punkte p welche eine PLZ haben oder Teil eines Weges/Gebietes
mit einer PLZ sind) tue:
  {
 Suche das Polygon P zu dieser PLZ+Staat -Kombination.
 Falls P nicht existiert, 
   {
  lege P mit diesem eine Punkt an.
   }
 Falls P existiert und p nicht in P enthalten ist:
   {
  Füge p dem Polygon P hinzu und entferne überflüssige Punkte
  (z.B. Graham Scan wobei bekannt ist, dass die Punkte in
   P ja schon sortiert sind.)
   }
  }

Mein ihr das wäre effizient so als Online-Algorithmus?
Oder doch lieber erst alle Punkte sammeln und dann Graham?
Auf mehrere Worker-Threads liesse sich das auf jeden Fall
schonmal verteilen.

Ahnung wie man Ausreisser erkennen kann (z.b. Tippfehler)?

Irgendeine Idee wie sich das mit dem disjunkt machen lässt?

Irgendwer hatte sowas schon mal in Österreich gemacht.
Erinnert sich noch wer daran wer das war und unter welchem
Topic das auf welcher Mailingliste war?

Marcus

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

Re: [Talk-de] Routing

On Wed, 21 Oct 2009 09:51:59 +0200, qbert biker qbe...@gmx.de wrote:
 Also versuch ich mal in Muenchen zu routen. Bis vor kurzem
 waren die kreuzungsfreien mehrspurigen Bereiche des 
 Mittleren Rings als Trunk eingetragen, dann wieder als 
 primary. Wenn ich trunk auch nur ansatzweise auswerte,
 wird dadurch das Routing komplett umgeschmissen, ohne dass


Was meinst su mit auch nur ansatzweise auswerte?
Es ist eine für dein Fahrzeug nutzbare Strasse, fertig.

Was wird komplett umgeschmissen?

Für welche Art von Fahrzeug hast du geroutet und optimiert
nach welcher Metrik?

Welches Navi hast du überhaupt verwendet?

 sich baulich irgendwas veraendert haette oder es eine
 dokumentierte Aenderung an der Klassendefinition 
 gegeben haette. Ich stehe als Navientwickler einfach vor
 der Situation, dass mein navi ploetzlich Routen auswirft,
 die fuer den Fahrer unbefriedigend sind.
 
 Das nennt man ueblicherweise Showstopper.
 
 Ueber den Hintergrund des geaenderten Mappings kann man 
 jetzt Vermutungen anstellen. Vielleicht hat sich jemand
 dran gestoert, dass diese Bereiche zwar alle technischen
 Voraussetzungen des trunks erfuellen, aber das KFZ-Strassen-
 Schild fehlt (das gibts da nur in/an den Tunneln), aber

Was hat die Eigenschaft dass es eine KFZ-Strasse ist
mit der Klassifikation als Trunk zu tun?
Beide Tags sind orthogonal.

 letztendlich ists egal, das Mapping wurde geaendert und
 ich habe keinen Einfluss drauf. 



 Ergo:
 Routerentwicklung braucht eine Mindeststabilitaet bei den
 Attributen und Klassen ueber eine Flaeche hinweg.

Ja

 Ob es
 nach 2 Jahren (damls waren in einigen Ecken schon genug
 Daten da um realistisch zu routen) immer noch noetig ist,
 grundlegende Definitionen in Frage zu stellen?

Nein, sollte nicht mehr passieren.


Marcus

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

Re: [Talk-de] Routing

On Wed, 21 Oct 2009 10:19:51 +0200, qbert biker qbe...@gmx.de wrote:
  Original-Nachricht 
 Datum: Wed, 21 Oct 2009 10:03:50 +0200
 Von: marcus.wolsc...@googlemail.com
 An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org
 Betreff: Re: [Talk-de] Routing
 
 Was meinst su mit auch nur ansatzweise auswerte?
 Es ist eine für dein Fahrzeug nutzbare Strasse, fertig.
 
 Reisezeitmodellierung und Priorisierung also der Versuch
 dem Fahrer gute Information zu geben, wo er am besten
 durch kommt.
  
 Was wird komplett umgeschmissen?
 
 Alle Routen in der Umgebung unter der (richtigen)
 Voraussetzung, dass eine kreuzungsfreie Strasse fast
 immer schneller ist als die Ampelstrassen der
 Umgebung (auch bei Stau).

Dann wirst du deine Metrik wohl noch etwas tunen müssen,
wenn dir die Qualität der nach deiner Metrik besten Route
noch nicht reicht.
Du hast mit lanes= und traffic_lights und ganz wichtig
maxspeed, ... jede Menge zusätzlicher Daten zur Verfügung.

Ich denke mal nicht dass auf dem Kreuzungsfreien Ring nur
50 gilt, oder? Wenn nicht wäre der auch kaum schneller als
eine Grüne Welle auf einer highway=primary mit gleicher
Spur-Anzahl in der Stadt.



Marcus

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

Re: [Talk-de] Routing

On Wed, 21 Oct 2009 10:39:45 +0200, qbert biker qbe...@gmx.de wrote:
 Aber es bleibt als Kernproblem, dass der Entwickler des
 Routingalgos i.A. das nicht leisten kann, denn er ist weder 
 vor Ort, noch hat er die Kapazitaet, das in der Flaeche 
 zu pruefen. Und es ist fuer ihn nicht erkennbar, ob es
 nur eine Spur gibt, oder ob nur kein Wert eingetragen 
 wurde, wenn er nur die Daten hat.

Ja.
Die Tags wie lanes=zahl gibt es ja.
Wenn das nicht getagged ist sehe ich das als unvollständig
gemappte Daten und nicht als Problem an. Wenn sich ein Nutzer
dran stöhrt muss er es halt mappen. (Ich zumindest habe dafür
einen schönen grossen Knopf edit visible area eingebaut.)

 Der Entwickler, der auf Basis der OSM-Attibute Algos schreibt,
 muss sich quasi blind darauf verlassen koennen, dass sich
 die Daten innerhalb einer Definition bewegen. 

Ja, das müssen wir.
Ich nehme an die von mir zusammengetragenen
http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing
sind dir geläufig?
Da habe ich versucht eindeutige Auswertungs-Regeln für
die momentan tatsächlich benutzten Tags zusammen zu tragen.

Wenn du noch was mit Lanes oder gute Heuristiken findest,
bitte hinzufügen. Das wird auch andere Interessieren.

 Fuer diesen Zweck, also der Arbeitsteilung zwischen Mapper
 und Anwendungsentwickler, gibts ausgefeilte Attributierungsmodelle
 wie das vor Urzeiten von der EU gefoerderte GDF. Leider merkt 
 man dem sein Alter deutlich an, aber es liefert immer noch 
 gute Anhaltspunkte, was man verbessern kann.
 
 Gruesse Hubert

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

Re: [Talk-de] Routing

On Wed, 21 Oct 2009 12:59:50 +0200, qbert biker qbe...@gmx.de wrote:
  Original-Nachricht 
 Datum: Wed, 21 Oct 2009 11:27:53 +0200
 Von: marcus.wolsc...@googlemail.com
 An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org
 Betreff: Re: [Talk-de] Routing
 
 
 Dann wirst du deine Metrik wohl noch etwas tunen müssen,
 wenn dir die Qualität der nach deiner Metrik besten Route
 noch nicht reicht.
 
 Wenn ich die Information des kreuzungsfreien Ausbaus 
 nicht habe, ist das ziemlich trostlos. Die ganzen 
 Aenderungen bewirken, dass ich mit einem Netz durchteste
 und es mit dem naechten Upload wieder heisst April, April.

Warum solltest du die Information über einen Kreuzungsfreien
Ausbau nicht haben?
Entweder hat die Strasse Kreuzungen oder sie hat T-Kreuzungen
mit highway=*_link -Strassen.

Erlich gesagt nutze ich die Information ob eine Strasse Kreuzungen
hat oder nicht garnicht (lediglich eine kleine Verzögerung wenn
nach Fahrtzeit optimiert wird und an einem besuchten Node mal
ein highway=traffic_lights steht) in meinen Metriken und sie liefern
gute und brauchbare Ergebnisse.

 
 Du hast mit lanes= und traffic_lights und ganz wichtig
 maxspeed, ... jede Menge zusätzlicher Daten zur Verfügung.
 
 Gut, maxspeed hab ich hier unterschlagen, das spielt aber
 Ausserorts die groessere Rolle, ausser in Temo-30-Zonen.

Also wenn ich mit maxspeed=60 über den Karlsruher Ring fahre
oder mit maxspeed=50 über die parallelen Strassen macht das
einen grössen Unterschied.
Wirklich kreuzungsfrei aufgebaute Durchgangsstrassen haben
fast immer eine maxpeed von 60 oder 70 auf den Schildern an
den Auffahrten innerhalb der geschlossenn Ortschaft.

 Ich denke mal nicht dass auf dem Kreuzungsfreien Ring nur
 50 gilt, oder? Wenn nicht wäre der auch kaum schneller als
 eine Grüne Welle auf einer highway=primary mit gleicher
 Spur-Anzahl in der Stadt.
 
 Meine tracks sprechen eine ganz andere Sprache, besonders
 weil gruene Wellen eine Idealvorstellung sind, die man
 selten antrifft. Dann reicht die Linksabbiegerspur mal
 nicht oder sie fehlt und die Welle bricht.

 Erfahrungswert (aus tracks): 
 Sa, So, Nacht, Ring: ca. 50-60kmh, Umgebung 30kmh
 Werktags, Ring 20-40kmh, Umgebung 20kmh oder weniger

Und welche Höchtgeschwindigkeit ist auf diesem Ring
jetzt ausgeschildert?


Marcus

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

Re: [Talk-de] Routing

On Wed, 21 Oct 2009 13:34:22 +0200, Martin Koppenhoefer
dieterdre...@gmail.com wrote:
 Am 21. Oktober 2009 11:27 schrieb  marcus.wolsc...@googlemail.com:

 Ich denke mal nicht dass auf dem Kreuzungsfreien Ring nur
 50 gilt, oder? Wenn nicht wäre der auch kaum schneller als
 eine Grüne Welle auf einer highway=primary mit gleicher
 Spur-Anzahl in der Stadt.
 
 das stimmt, wobei man von grüner Welle nicht immer ausgehen kann. In
 Tübingen (zugegeben etliche Klassen kleiner als München) gibt es z.B.
 auf den Hauptstrecken z.T. rote Wellen (sobald es grün wird, wird
 die nächste Ampel rot *SCNR*), und das, weil die Grünen schon seit
 langem sehr stark sind im Gemeinderat.

Ich denke Tübingen können wir als Sonderfall abtun.
Die einzige Stadt wo z.b. das teure Travelbook reproduzierbar
abstürzt.
Bei denen bin ich mir nichmal sicher ob die Strassen
in einer euklidischen Geometrie liegen. ;)
(Ich musste öfter mal durch diese Stadt fahren. Da will man
 nicht rein.)

Marcus

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

Re: [Talk-de] Navigations-Software Roadee mit OSM-Dat enbasis im?Vergleich bei Heise

2009-10-19 Thread marcus.wolschon

On Sun, 18 Oct 2009 21:46:49 + (UTC), Sven Geggus
li...@fuchsschwanzdomain.de wrote:
 Longbow4u 2long...@gmx.de wrote:
 
 Leider wird der Vergleich der Navigationssoftware, so er denn kommt,
 wahrscheinlich nicht besonders erfreulich ausfallen (was nicht
 ausschließlich am
 zugrundeliegenden Kartenmaterial liegt). Einige der Routenvorschläge
 sind noch
 ziemlich buggy. So wird häufig auf Feld-oder Waldwegen zum Ziel
 geleitet, obwohl
 die befestigte Hauptstraße nur unwesentlich länger ist
 
 Sowas liegt aber ja wohl ausschließlich am Routingsalgorithmus. 

Falsch. Das ist die Metrik und die ist was anderes als
der Routing-Algorithmus.

Metrik=Wie viel kostet diese Strasse

Algorithmus=Wie finde ich den Weg mit minimalen oder kleinen Kosten von A
zu einem beliebigen Element der Menge B

Bringt das doch bitte nicht dauernd durcheinander.

Feld-
 oder Waldwege sind nunmal nichts für Autofahrer. Spätestens wenn man
 die Geschwindigkeit hier auf max 5km/h setzt dürfte da nix mehe von
 übrig bleiben. der Garmin hat ja auch gerne mal solche Probleme. Ich
 nehme an, das liegt schlichtweg daran, dass solche Wege bei
 kommerziellem Kartenmaterial überhaupt nicht existieren.
 
 Gruss
 
 Sven

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

[Talk-de] Welche Unterstützung wird gebraucht

2009-10-19 Thread marcus.wolschon


Hallo Leute,


welche Art von Unterstützung seitens Firmen welche mit Geodaten arbeiten
(aber kein Kartenmaterial spenden können) würde aktuell dem
OSM-Projekt am besten helfen?

Bisher sind mir eingefallen:
* GPS-Tracks (auch anonymisiert solange die Timestamps sinnvoll bleiben)
* Server (mit viel Ram und schnellen Platten) sponsoren
* Einfache Möglichkeit für Endnutzer ohne OSM-Wissen zum Erfassen,
  Korrigieren oder Fehler-Melden für die OSM-Karte in einem Produkt
* auf fehlende Ortschaften, Strassen und Fehler hinweisen
* eine Adresse-Koordinate -Suche auf der OSM-Karte anbieten
* ...

Gruss,
Marcus

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

Re: [Talk-de] Navigations-Software Roadee mit OSM-Datenbasis im Vergleich bei Heise

2009-10-19 Thread marcus.wolschon

On Mon, 19 Oct 2009 09:19:51 +0200, Martin Simon grenzde...@gmail.com
wrote:
 und bei getrichelter Linie darf ich eine Abbigespur nicht
 zum überholen missbrauchen... Führ das Routing sehe ich separate
 OSM-Ways für Abbiegepuren daher ehr als hilfreich an...

Inwieweit sollten sie hilfreich sein, solange sie von
separaten Strassen nicht unterschieden werden können?
(und jetzt bitte kein aber das ist doch offensichtlich
 wenn die alle parallel laufen.)

Willst du ein bitte rechts abbiegen auf UNBENANNT
und dann ein bitte rechts abbiegen auf Strasse XYZ
wenn du eine Abbiege-Spur auf Strasse XYZ hast?

Spuren sind was eigenes und brauchen ein Tagging-Schema.
Das mit Wegen zu machen ohne diese irgendwie eindeutig
mit einer allgemein bekannten und dokumentiertem Art
zu taggen und in einer Weise mit der auch Navis ohne
Unterstützung für Fahrspuren zurecht kommen (Garmin-Export
z.B.) können macht nur bestehende Daten kaputt.

Marcus

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

Re: [Talk-de] Statusseite der Landesstraßen in Baden-W ürttemberg neu angelegt

2009-10-16 Thread marcus.wolschon


Wuderbar,

ein Freiwilliger der eine Datenbank-Anwendung für solche Listen schreibt.


Gruss,
Marcus


On Fri, 16 Oct 2009 13:48:33 +0200, FlaBot fla...@googlemail.com wrote:
 Super Aktion 
 
 
 ... aber kann man sowas nicht über eine Datenbank laufen lassen ?
 Tabellen konnte man so dynamisch erzeugen. Den Datenbankinhalt
wöchentlich
 per
 Dump updaten ..
 
 Liebe Grüße Dirk
 
 
 
 Ich habe die Status-Tabellen auf 6 Unterseiten verteilt.
 Die eingetragenen Relationen wurden aus dem Baden-Württemberg Dump
 extrahiert.

 Viel Spaß beim Kontrollieren der Straßen.

 Grüsse
 Werner (werner2101)

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

 
 
 
 -- 
 Wikipedia -- http://tools.wikimedia.de/~flacus/IWLC/
 
 OSM -- http://osm.flacus.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] OSM-Handheld für 58,80Euro... (P rimer2) mit Moving OSM Map

2009-10-15 Thread marcus.wolschon

On Wed, 14 Oct 2009 17:36:26 +0200, Tobias Wendorff
tobias.wendo...@uni-dortmund.de wrote:
 Marcus Wolschon schrieb:
 Kannst du mir bitte ein paar Sender nennen, die solche RDS-Gruppen
 verschicken?
 Mir ist bei meinen Tests nie so etwas in der Praxis in die Antenne
 gekommen.
 Wäre überaus interessant.
 
 Ich schätze mal, er meint den RASANT-Dienst, hier die Koordinaten:

http://www.lverma.nrw.de/produkte/raumbezug/sapos/dienste/images/refkoord.txt

Danke.
Ich habs mir mal notiert.
http://travelingsales.sourceforge.net/bugs/view.php?id=169

Marcus

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

Re: [Talk-de] OSM-Handheld für 58,80Euro... (P rimer2) mit Moving OSM Map

2009-10-14 Thread marcus.wolschon

On Wed, 14 Oct 2009 11:29:31 +0200, Garry garr...@gmx.de wrote:
 Garry schrieb:
 Gerade entdeckt:
 Es gibt eine OSM-Software für den Primer2, eine (fast) outdoortaugliche

 ARM-Entwicklungsumgebung in der Grössenordnung eines Garmins 

 http://www.stm32circle.com/projects/project.php?id=75

 Die Hardware gibt es hier:
 http://elmicro.com/de/stm32primer2.html
   
 Bevor das als Werbung für einen Händler missverstanden wird - der 
 Ursprung steckt in einer
 Kostenabschätzung zwischen einer Eigenentwicklung einer speziellen 
 Hardware für den OSM-Höhendatenlogger
 und der Lösung mittels einer fast fertig-Hardware die sich auch für 
 andere OSM-Anwendungen eignet.

The STM32-Primer2 is equipped with an STM32F103VET6, one of the new ST,
Cortex-based, 32-bit
microcontrollers. The main characteristics of this device are:
· ARM 32-bit Cortex™-M3 CPU, 72 MHz, 90 DMips with 1.25 DMips/MHz,
· 512KB of Flash program memory, 64KB SRAM,
· Embedded oscillators (for high-speed crystal + RTC),
· SWD debug interface,
· Fast input/output: up to 80 I/Os, ADC, DAC,
· Embedded communication peripherals: USB 2.0, CAN, USART, SPI, I2C, LIN,
IrDA
· Multiple timers; watchdog, PWM, Systick timer, ...

Das 64KB Ram für eine moving map+Datenlogger reichen ist erstaunlich.
Für mehr wird es wohl nicht reichen (Weiterentwicklung).

Schaden. Nettes Angebot.

Marcus

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

Re: [Talk-de] OSM-Handheld für 58,80Euro... (P rimer2) mit Moving OSM Map

2009-10-14 Thread marcus.wolschon

On Wed, 14 Oct 2009 13:52:52 +0200, Garry garr...@gmx.de wrote:
 marcus.wolsc...@googlemail.com schrieb:

 The STM32-Primer2 is equipped with an STM32F103VET6, one of the new ST,
 Cortex-based, 32-bit
 microcontrollers. The main characteristics of this device are:
 · ARM 32-bit Cortex™-M3 CPU, 72 MHz, 90 DMips with 1.25 DMips/MHz,
 · 512KB of Flash program memory, 64KB SRAM,
 · Embedded oscillators (for high-speed crystal + RTC),
 · SWD debug interface,
 · Fast input/output: up to 80 I/Os, ADC, DAC,
 · Embedded communication peripherals: USB 2.0, CAN, USART, SPI, I2C,
 LIN,
 IrDA
 · Multiple timers; watchdog, PWM, Systick timer, ...

 Das 64KB Ram für eine moving map+Datenlogger reichen ist erstaunlich.
 Für mehr wird es wohl nicht reichen (Weiterentwicklung).

 Schaden. Nettes Angebot.
   
 Dann ist Dir wohl der integrierte microSD-Slot entgangen...

Ist er nicht. Ich dachte daran ob es möglich wäre
dem einfache Editor-Funktionen zu geben aber dazu
reichen 64KB halt nicht und Auslagern von gerade bearbeiteten
Daten auf langsamen, seriellen Flash ist nicht sinnvoll.
Dafür müsste es halt mit dem Ram für den ganzen gerade bearbeiten
Datenbestand reichen.


Marcus

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

Re: [Talk-de] OSM-Handheld für 58,80Euro... (P rimer2) mit Moving OSM Map

2009-10-14 Thread marcus.wolschon

On Wed, 14 Oct 2009 14:12:05 +0200, Tobias Wendorff
tobias.wendo...@uni-dortmund.de wrote:
 Hallo Rolf,
 
 Rolf Meyerhof schrieb:
 Einen genauen Höhenmesser kenne ich aus Elektor 07 / 2009. Der wird
 sogar für Ultralights benutzt. Wie soll das eigentlich gehen mit der
 Höhenmessung? Der Luftdruck für die Höhe ist doch immer abhängig vom
 aktuellen Luftdruck für die momentane Position. Und wo bekommst du denn
 immer her?
 
 Sascha, Ralph und ich haben uns im letzten Jahr ein System mit
 einer Referenzstation ausgedacht, die ebensolche Probleme
 kompensieren soll. Man kann auch ein Messnetz aufbauen.

Referenzstationen für Luftdruck?
Sowas geht?
Ist das schonmal getestet worden?
Ich denke jetzt mal an Windschatten und Bewegung.

Marcus

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

Re: [Talk-de] Liste aller Grenzrelationen der Staaten

2009-10-12 Thread marcus.wolschon

On Mon, 12 Oct 2009 00:50:31 +0200, Frederik Ramm frede...@remote.org
wrote:
 Eine Datenbank, die regelmaessig nur mit diffs gefuettert wird - 
 Ausnahme die minute-replicate-Diffs - wird langsam inkonsistent, weil 
 prinzipbedingt ein ganz kleiner Teil von Edits verloren gehen *kann* bei 
 so einem Diff (auch Stunden- oder Tagesdiffs).

Kannst du das näher erläutern?

Marcus

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

Re: [Talk-de] Liste aller Grenzrelationen der Staaten - L ücken in Diffs

2009-10-12 Thread marcus.wolschon

On Mon, 12 Oct 2009 09:23:29 +0200, Frederik Ramm frede...@remote.org
wrote:
 Hallo,
 
 marcus.wolsc...@googlemail.com wrote:
 Eine Datenbank, die regelmaessig nur mit diffs gefuettert wird - 
 Ausnahme die minute-replicate-Diffs - wird langsam inkonsistent, weil

 prinzipbedingt ein ganz kleiner Teil von Edits verloren gehen *kann*
bei

 so einem Diff (auch Stunden- oder Tagesdiffs).
 
 Kannst du das näher erläutern?
 
 Osmosis erzeugt die Diffs auf dem zentralen Server aufgrund der 
 History-Tabelle mit einem Query, der alles abfragt, was zwischen zwei 
 Zeitpunkten passiert ist. Aufgrund der Transaktionsisolierung bekommt 
 Osmosis aber nur die Daten, die einen Timestamp im fraglichen Fenster 
 haben UND deren Transaktion schon committed ist. Durch diff-Uploads kann 
 es einige sehr lang laufende Transaktionen geben.
 
 Beispiel: Das stuendliche Diff fuer den Zeitraum 13:00-14:00 wird um 
 14:20 erzeugt und hat alle Daten mit Timestamp 13:00-14:00. Wenn um 
 12:59 eine Transaktion begonnen wird, die bis 13:21 laeuft, so 
 erscheinen um 13:21 ploetzlich lauter Daten in der Datenbank, die einen 
 Timestamp von 12:59 haben. Diese verpasst das Diff, und sie werden auch 
 im 14:00-15:00-Diff nicht drin sein.
 
 Fuer alle anderen Arten von diffs gilt das vergleichbar.

Danke für die Erklährung Frederik.

Mir ist da gerade etwas zu eingefallen:

Werden die Changeset-IDs linear hochgezählt?

Falls ja könnte man die Query so gestalten:

Select * from changesets where id  [grösste Chageset ID des letzten
Laufes]
OR id in [alle nicht aufgetauchten changeset IDs in einem geeignetem
Intervall]

der zweite Teil könnte möglicherweise genau diese Lücken finden.

Marcus

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

Re: [Talk-de] TMC-Import startet und braucht eure Hilfe

2009-10-09 Thread marcus.wolschon

Ich hab das Beispiel auf
http://wiki.openstreetmap.org/wiki/TMC/TMC_Import_Germany/Areas

nochmnal überarbeitet, auf den einzelnen Area1,2,3-Seiten verlinkt
und die Warnung auch in der Deutschen Version nachgetragen.

Soweit sieht, was ich stichprobenartig durchgesehen habe super aus.
Danke Leute! :)

Marcus

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

Re: [Talk-de] Relationsstruktur fuer geografische Einordnun g - is_in

On Thu, 8 Oct 2009 07:40:00 +0200, Bernd Wurst be...@bwurst.org wrote:
 Das is_in-Tag ist meiner Meinung nach noch zu schlecht in JOSM
integriert, 
 auch wenn ich keine Endlösung bieten kann, wie das sein sollte.
Letztlich 
 kann man über das is_in-Tag aber schon ganz gut Zuordnungen treffen.
Seit 
 (Anfang des Jahres?) mal ein Bot gelaufen ist, der das Chaos grob
 aufgeräumt 
 hat, ist das eigentlich ganz nützlich.

Was gäbe es da zu integrieren?

Das is_in -Tag ist einfach unbenutzbar spezifiziert.
Du kannst da sonstwas rein schreiben.

Schonmal versucht anhand der is_in -Tags z.b. alle
zu einem Regierungsbezirk gehörenden Orte zu finden?
Oder zu welchem XYZ jetzt irgendwas gehört für irgendein
festes XYZ?
Bei einen steht nichts drin, bei einigen das Bundesland
in einer von 10 verschiedenen Schreibweisen, bei einigen .

Das bestehende is_in -Tag ist einfach für keinerlei Verwendung
nutzbar. Es steht willkürlicher Müll drin und jede Suche nach
einem Bestimmten Wert in diesem Tag ist zum Scheitern verurteilt.


Marcus


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

Re: [Talk-de] Relationsstruktur fuer geografische Einordnung

On Thu, 8 Oct 2009 07:49:16 +0200, Bernd Wurst be...@bwurst.org wrote:
 Hallo.
 
 Am Donnerstag, 8. Oktober 2009 schrieb Marcus Wolschon:
 Dann brauchen wir aber endlich eine andere Möglichkeit die Polygone zu
 finden in denen ein Punkt enthalten ist als nur lade halt das
 Planet-File
 und prüfe alle Ways darin.
 
 Ist es so schwer, einfach mal auf maßlose Übertreibung zu verzichten?

Was ist daran masslos?
Gegeben einen Punkt Lat+Lon und einen leeren Windows-Rechner
mit Browser und existierende Polygone.
Sage mir bitte, wie finde ich heraus in welchem Ort, Kreis und Bundesland
sowie PLZ-Gebiet dieser Punkt ist ohne bekannte Relations-IDs und ohne ein
Gebiet von der maximalen Grösse eines Bundeslandes +20% zu durchsuchen
oder
mir per OSMXAPI alle PLZ-Gebiete, Orte, Kreise und Bundesländer eines
Suchgebietes zu holen und wenn nichts kommt meinen Such-Radius immer wieder
auszuweiten?
XAPI macht hier auch nichts anderes als die gesammte Datenbank zu
durchsuchen.
Suchen, nicht Navigieren wohlgemerkt.

 Für die allermeisten Fälle würde man eben nicht das planet-file
 runterladen 
 sondern z.B. über die XAPI alle boundaries in dem Bereich den man
 überhaupt 
 beachtet.

XAPI hat genug Timeouts um nicht für ständig reinkommende Anfragen
nutzbar zu sein. Streckenweise ist es stundenlang nicht möglich eine
einzige Suche abzusetzen.

 Vermutlich sogar einfach (wenn man in D arbeiten will) die 
 Deutschland-Grenz-Relation und dann über die vorhandenen Verkettungen
die 
 Kreis- und Gemeindegrenzen.

Diese Verkettungen bis hinunter zur Ortschaft sind ja gerade Relationen auf
die wir ja als Hypothese verzichten mögen.

 
 Der Datenumfang dieser Aktion wäre nur ein winziger Bruchteil des
 planet-file.

Der durchsuchte Datenumfang hat sich nicht verringert. Nur der Ort
wo gesucht wird.

 Zudem kann man ja Problemlos das Parsing einmal machen und dann in einem
 für 
 sich geeigneten Format an den Daten der eigenen Anwendung hinterlegen. So

 schnell ändern sich diese Dinge ja nicht.

Dass genau das zentral gemacht wird ist ja mein Vorschlag als Alternative
zu
Relationen.


Marcus

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

Re: [Talk-de] Relationsstruktur fuer geografische Einordnun g - is_in

On Thu, 8 Oct 2009 08:30:03 +0200, Bernd Wurst be...@bwurst.org wrote:

Hallo Bernd.


 Wer nützliche Daten produzieren will, schaut sich Bestehendes an und
 trägt 
 seine Daten äquivalent ein. So war das immer und so funktioniert das
auch.

Leider hat das im Falle dieses Tags nicht geklappt.
Es gibt einfach keinen Konsens was da drin steht.
Passiert halt bei unserem Ansatz auch hin und wieder.

 Schonmal versucht anhand der is_in -Tags z.b. alle
 zu einem Regierungsbezirk gehörenden Orte zu finden?
 
 Da es Regierungsbezirke in den meisten Bundesländern nicht gibt und
diese
 auch 
 in der persönlichen Empfindung quasi keine Rolle spielen, wurden die des

 öfteren nicht angegeben. Das ist korrekt, aber kein Grund den Kopf in
den 
 Sand zu stecken. Vermutlich brauchst du für das was du machen willst die

 Regierungsbezirke auch gar nicht, oder?
 
 Und selbst wenn, die Regierungsbezirke enden immer an Landkreisgrenzen.
Du 
 kannst mit einer sehr überschaubaren festen Liste diese Zuordnung anhand
 der 
 Landkreise treffen.

http://tagwatch.stoecker.eu/Germany/De/ignored_is_in.html

Wie viele siehst du in diesen 300 wo der Landkreis halt nicht
im Wert des is_in -Tag steht?
Genau diese wirst du dann in deiner Suche nicht finden.

Wenn ich eine Datenbank habe will ich nicht für alle Länder dieser
Erde eine festen Liste diese Zuordnung führen. Dann bräuchte
ich die Karte nicht mehr weil ich ja die gesuchte Zuordnung bereits habe.

 Oder zu welchem XYZ jetzt irgendwas gehört für irgendein
 festes XYZ?
 Bei einen steht nichts drin, bei einigen das Bundesland
 in einer von 10 verschiedenen Schreibweisen, bei einigen .
 
 Gib mir bitte das Beispiel für ein Bundesland, das in 10 verschiedenen 
 Schreibweisen in irgendwelchen is_in steht?


http://tagwatch.stoecker.eu/Germany/De/ignored_is_in.html
erkennst du hier irgendwelche einheitliche Nutzung?
Da steht mal dieses, mal jenes drin. Mal nur der Name des
Ortes, mal das Bundesland, mal 
Durchsuche die Tag-Werte nach irgendwas und du wirst die hälfte
nicht finden weil an gerade dem jetzt eben nur andere
Hirarchie-Ebenen dran standen und die gesuchte nicht im Tag-Wert
ist.
Da ist es zuverlässiger dieses Tag zu ignorieren und mit
Polygonen/Multipolygonen und/oder Relationen zu arbeiten.
Und genau so eine genauer spezifizierte Relation wird gerade
im Wiki ausgearbeitet und hoffentlich irgendwann vorgeschlagen
oder einfach mal testweise benutzt.

 Aber mit Polemik und destruktivem Gerede wurde hier noch selten ein
 Kompromiss 

Es geht nicht um einen Kompromiss sondern um eine Begründung warum
ein Ersatz für das chaotische is_in sinnvoll ist.

 erzielt. Ich vertraue da lieber den Anwendungen, die das *jetzt* schon 
 *aktiv* nutzen.

Nenn mir bitte eine die is_in nutzt und funktioniert.

Marcus

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

Re: [Talk-de] TMC...

On Thu, 08 Oct 2009 09:38:16 +0200, Frederik Ramm frede...@remote.org
wrote:
 Hallo,
 
 ich hab das mit dem TMC nur am Rande verfolgt, aber wenn ich den 
 note-Tag richtig lese, dann ist dies hier...
 
 http://www.openstreetmap.org/browse/relation/282430
 
 ... wohl ein unerwuenschter Effekt? (Scheint mir auch vernuenftig, sowas 
 nicht hochzuladen, denn diese TMC-Tags und Rollenbeschreibungen a la
 
 member type=node ref=30897223 role=contains: 
 TMC:cid_58:tabcd_1:LocationCode=3094 Osterholz-Scharmbeck/
 
 scheinen mir nicht gerade dem OSM-Grundsatz zu folgen, dass wir 
 menschenlesbare Daten haben wollen ;-)

Genau.
Das steht gross und breit dran, dass man die nicht so 1:1 hochladen soll.
Das .osm -Format hab ich da nur gewählt weil es das sinnvollste ist
um im JOSM mit 2 Layern herauszufinden was zu was gehört. (Vor allem
mit den Europa- und Bundes-Strassen und deren Kreuzungen ginge das sonst
maximal noch über irgendwelche gerenderten Bilder und einen mit viel, viel
Arbeit aufgesetzten WMS-Server)

Hat wohl jemand versehentlich den falschen Layer hochgeladen.

Marcus

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

Re: [Talk-de] TMC...

On Thu, 08 Oct 2009 09:57:09 +0200, Frank Sautter
openstreet...@sautter.com wrote:
 Frederik Ramm schrieb:
 scheinen mir nicht gerade dem OSM-Grundsatz zu folgen, dass wir 
 menschenlesbare Daten haben wollen ;-)
 
 ist mir heute morgen auch schon aufgefallen ;-)
 
 ich finde es ok, die TMC codes bei uns mit aufzunehmen, aber eher im 
 sinne eines ref-tags, das auf externe daten (was die objekte in der 
 TMC-liste ja darstellen) referenziert.
 
 das zeugs, was aber da teilweise gerade reinwandert, hat imho nichts in 
 unseren osm daten zu suchen, weil es unsere daten unnötig aufbläht, 
 nicht vernünftig menschenwartbar und eigentlich vollkommen redundant ist

 (mal ganz abgesehen von DO NOT UPLOAD THIS ENTITY! IT IS FOR REFERENCE 
 ONLY.)


*Zustimm*
Da soll das eine Tag mit dem LocationCode rein, später bei Wegen
zusätzlich die Nummer von Vorgänger/Nachfolger (weil der Code alleine
da nicht ausreicht) und optional vieleicht noch LCLversion oder weil
es sinnvolle Information ist Class.

Wie kann ich da am sinnvollsten ein Auge drauf halten, dass sowas
nicht öfter passiert? OSMXAPI ist nicht immer aktuell, oder?
Tagwatch war täglich oder wöchentlich?

Marcus

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

Re: [Talk-de] TMC...

On Thu, 8 Oct 2009 10:07:07 +0200, Sven Anders s...@anders-hamburg.de
wrote:
 Hat schon jemand den User der es hochgeladen hat (höflich)
angeschrieben?
 
 Das wäre IMHO das beste vorgehen. Ich will nur verhindern das er in
Mails 
 ertrinkt.

Schon geschehen. Hab den User aus der History.

Marcus

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

Re: [Talk-de] Relationsstruktur fuer geografische Einordnun g - is_in

On Thu, 8 Oct 2009 10:10:10 +0200, André Riedel riedel.an...@gmail.com
wrote:
 Am 8. Oktober 2009 10:00 schrieb  marcus.wolsc...@googlemail.com:
 http://tagwatch.stoecker.eu/Germany/De/ignored_is_in.html
 
 Hier ist auch noch was schönes dazu:
 http://autobug.osm.lab.rfc822.org/lists/hierarchy.html

Danke.

Nett
wir haben 2 grosse Hirarchien unter
Bundesrepublik Deutschland und unter Germany,
ein frei schwebendes Hessen und jede Menge frei
schwebende Orte.

Marcus

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

Re: [Talk-de] Relationsstruktur fuer geografische Einordnung

On Thu, 8 Oct 2009 08:34:45 +0200, Bernd Wurst be...@bwurst.org wrote:
 Was willst du eigentlich alternativ haben? Dass jeder Punkt in irgend 
 einer Ich bin hier-Relation steckt?

Was mir am liebsten wäre, wäre entweder
a)
Ein Suchmöglichkeit die alle Polygone liefert in denen ein Punkt enthalten
ist. Als Gegenstück zur bounding-box -suche, die mir alle Objekte in einer
Region liefert.
Multipolygone müsste man dann immernoch von Hand alle durchprobieren
aber das sollten nur einige tausend sein. 

oder 
b)
Die Möglichkeit für daran interessierte zur konstruktiven Arbeit an einer
Ablösung des uneindeutigen is_in-Tags durch eine Relationen-Hirarchie
mit
sinnvollen Rollen bis hinunter zur Ortschaft/Stadtteil ohne ständig durch
Relationen sind böse torpediert zu werden.

Einfach weil eines von beiden den Aufbau von hochwertigen und nicht nur
irgendwie halbwegs funktionierenden Adress-Suchen so viel einfacher macht
und unsere Datenqualität gegenüber is_in massiv steigern könnte bei
gleichzeitiger
Verringerung der Redundanz und einfacherer Prüfung auf Korrektheit durch
den
einzelnen Mapper.
Dein dann muss man halt Preprocessing machen in allen Ehren aber dieses
Preprocessing muss nicht künstlich durch massiv inkonsistente und
unvollständige
Daten erschwehrt werden.
Sobalt du sowas wie ich habe auf x ein is_in=A und irgendwo hab ich ein
is_in=A,B
gelesen, also muss x in A und in B sein machen musst wirst du irre. Daher
ignoriere ich bei meiner Adressdatenbank is_in auch weitgehend und nutze es
nur
sekundär.


Marcus

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

Re: [Talk-de] TMC...

On Thu, 08 Oct 2009 10:40:55 +0200, SLXViper slxvi...@gmx.net wrote:
 Könnte man das nicht verhindern, indem man für diesen TMC-Layer
negative
 IDs benutzt? Um das dann hochzuladen, müsste man dann schon deutlich
 mehr Aufwand (als Upload klicken) betreiben, der dann die allermeisten
 (hoffentlich) davon abhält...
 

Ich habe negative IDs benutzt um den Schaden in so einem Fall gering zu
halten.
(statt existierender Objekte werden neue angelegt).
JOSM erlaubt das explizit.

Wenn jemand eine Idee hat, gerne.
z.B. könnte ich eine Versionsnummer  0 angeben oder so.

Marcus


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

Re: [Talk-de] Relationsstruktur fuer geografische Einordnun g - is_in

On Thu, 08 Oct 2009 11:00:42 +0200, Frederik Ramm frede...@remote.org
wrote:
 Hallo,
 
 Bernd Wurst wrote:
 Bundesrepublik Deutschland und unter Germany,
 
 Ja, groß (30.000 Einträge) und groß (118 Einträge). Quasi gleich
 groß. :)
 
 Bloss weil 
 irgendwas in Deutschland ist, kann man doch nicht alles in so eine 
 Relation stecken.

Die Relation für Deutschland hätte wohl 16 (zusätzliche) Einträge mit
einer Rolle
ala state oder ähnlich und wäre warscheinlich die gleiche Relation
die eh schon zum Zusammenfassen der Grenzen existiert.


 Da hat wohl wieder mal der deutsche Ordnungswahn 
 zugeschlagen... hups, was haben wir denn hier, einen kleinen Node, der 
 ist ja noch in gar keine Relation, hm, wo koennte der denn rein, 
 schliesslich muss alles schoen aufgeraeumt sein... ;-)

Jetzt mach du dich nicht lächerlich.

Mit dem is_in -Tag werden wir immer Einträge haben, die nicht zusammen
passen
und jede Menge die halt fehlen.
Das ist einfach ein technisch schlechter Lösungsansatz um ein
enthalten-sein
auszudrücken.
Was wäre an Polygonen/Multipolygonen bzw. einem Baum aus Relationen
schlechter als wie jetzt an jedem kleinen Objekt ein is_in zu haben, das
sagt das es in Europa ist und nur mit massiven Mehrdeutigkeiten und
Unvollständigkeiten geparsed werden kann?

Polygone machen sich soweit gut aber die Suche nach oben hin ist sehr
aufwendig
(wer diesen Aufwand treibt ob Server oder Client ist zweitrangig).
Relationen wie z.B. in der Deutschland-Relation als Member die
Bundesländer,
in denen ihre Kreise und kreisfreihen Städte, ... . Damit kann ich gleich
sehen: Kurfürstendamm ist in 12345 Berlin-Mitte in Deutschland und kann
umgekehrt
eine mit Adressen statt Lat+Lon referenzierte Geodaten als Datenspende
akzeptieren,
da ich DE - Berlin - Berlin-Mitte - PLZ 12345 - Kurfürstendamm
auflösen kann.

Marcus

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

Re: [Talk-de] Relationsstruktur fuer geografische Einordnung

On Thu, 8 Oct 2009 11:02:52 +0200, André Riedel riedel.an...@gmail.com
wrote:
 Irgendwie ;-) scheint es ja zu gehen. Nein, schau dir das folgende
 Beispiel mal an:
 http://old-dev.openstreetmap.org/~ojw/PlaceBrowser/

Stürzt bei Stuttgart ab und bei Herrenberg, Reutlingen, Horb am
Neckar,...
kommt garnichts.

Ich sag ja nicht dass es nicht geht sondern dass es unnötig aufwändig
und unnötig unvollständig und unnötig fehleranfällig ist das über
is_in zu machen.
Ausserdem bin ich mir sicher, dass der nicht nur is_in sondern mindestens
auch die Grenzen nutzt. Genau die statt is_in zu nutzen ist aber einer
meiner
2 alternativen Vorschläge.

Marcus

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

Re: [Talk-de] Relationsstruktur fuer geografische Einordnun g - is_in

On Thu, 08 Oct 2009 12:20:43 +0200, Ulf Lamping
ulf.lamp...@googlemail.com
wrote:
 Mit dem is_in -Tag werden wir immer Einträge haben, die nicht zusammen
 passen
 und jede Menge die halt fehlen.
 
 Ja, eine Unschärfe bleibt leider. Allerdings ist mir ein unscharf (nicht

 falsch) eingetragener is_in lieber als eine garnicht eingetragene 
 Relationszugehörigkeit.

Ich kann bei einer Suche keinen Unterschied erkennen ob kein is_in gefunden
wird oder ob das Objekt nicht in einer entsprechenden Relation (Variante B)
oder nicht in einem entsprechenden Polygon(Variante A, robuster) ist.


 Das ist einfach ein technisch schlechter Lösungsansatz um ein
 enthalten-sein
 auszudrücken.
 
 Beide Varianten haben so ihre Vor- und Nachteile.
 
 Technisch sind die Relationen zwar auch aus meiner Sicht besser, aber 
 für einen Crowdsourcing Ansatz ist is_in für den Mapper da draussen 
 (zumindest aktuell) einfacher.
 
 is_in kann man halt recht einfach aus dem Kopf machen:
 
 Kleinkleckersdorf, Landshut, Bayern, Deutschland, Europa, Erde, 
 Sonnensystem, Milchstraße

In der Tat ist es natürlich einfacher zu mappen, nur ist es genauso
einfach eine Ebene zu vergessen oder eine andere Schreibweise zu verwenden
oder bei einer Änderung nicht alle Vorkommnisse zu bemerken.

Bei einem Polygon kann das nicht passieren und bei einer Relation
ist jedes in sie eingetragene Objekt auch mit grosser Sicherheit richtig.

Unterhalb der Ebene der Ortschaft/Stadtteil halte ich Relationen für
zu aufwendig, da muss es ein Polygon sein. Darüber ist mir beides Recht
aber is_in lehne ich dort ab.

 Die passende Relation muß man erstmal finden bzw. anlegen. Die aktuelle 
 einfache Benutzbarkeit der Editoren auf dem Gebiet der Relationen ist 
 hoffentlich bekannt.

Ich sehe das eher anders herum. Wenn keiner sie benutzt, werden die
Editoren auch nicht besser da weder Anforderungen erkannt werden noch
eine Priorität (um nicht Leidensdruck zu sagen) für solche Verbesserungen
besteht.

 Ergo: Solange das Handling der Relationen noch nicht wirklich schön 
 ist, kommen wir mit is_in erstmal schneller voran. Wenn wir später die 
 Editoren soweit haben, können wir die is_in immer noch mit vertretbarem 
 Aufwand in Relationen umwandeln ...

Genau diesen vertretbaren Aufwand bezweifle ich.


Marcus

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

Re: [Talk-de] TMC-Import startet und braucht eure Hilfe

On Wed, 7 Oct 2009 20:49:51 +0200, Marcus Wolschon mar...@wolschon.biz
wrote:
 2009/10/7  marcus.wolsc...@googlemail.com:

 Auf

http://wiki.openstreetmap.org/wiki/TMC/TMC_Import_Germany/Areas/3600_to_3700
 hab ich jetzt zum Testen eine der neu generierten Wiki-Tabellen.

 * kein Link auf JOSM mehr
 * Link zum RemoteControl-Plugin oben
 * neu: Bounding-Box downloads

 Was noch kommt:
 * Bounding-Box in .osm -Dateien
 * irgendwie die ganzen Wiki-Tabellen aktualisieren.
  (Captcha macht Probleme.)

http://wiki.openstreetmap.org/wiki/TMC/TMC_Import_Germany/Areas1 besteht
schonmal fast komplett
aus den neu generierten Tabellen. (keine Angst, done-Einträge hab ich
übernommen)
und in Areas1, Areas2 und Areas3 ist eine Warnung drin, dass man die
.osm nicht hochladen soll.


Marcus

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

Re: [Talk-de] Relationsstruktur fuer geografische Einordnung

On Thu, 8 Oct 2009 13:39:36 +0200, Florian Lohoff f...@rfc822.org wrote:
 On Thu, Oct 08, 2009 at 01:33:45PM +0200, Marcus Wolschon wrote:
 Super.
 Jetzt müsste das nur auch in MySQL tun und in der Api oder
 OSMXAPI angeboten werden. (Aber bitte ihne adminlevel und border
 sondern natürlich für allgemeine Polygone.)
 
 Wenn du MySQL vernuenfige GIS extensions beibiegst dann geht das auch da.

Darauf habe ich keinen Zugriff. Die Server stehen in London.

 Und OSMXAPI ist tot - Rest in piece(es) - Das dingen ist fuer
irgendwelche
 nutzung viel zu instabil und langsam.

Etwas besseres als OSMXAPI haben wir halt nicht für Suchen nach etwas
anderes als der ID.
Die Alternative ist halt für jeden der ein popeliges Shell-Script
schreiben will was so eine Suche mal ebnen für ein Dutzend Elemente
braucht zu zwingen ein Postgresql + Postgis für seine Architektur
runterzuladen, einzurichten, Datenbank anzulegen, Rechte vergeben,
Planet laden, importieten, fluchen weil irgendwas nicht tut.

Oder halt den Planet/Landes-Auszug durch osmosis mit einem speziellen
Task zu jagen und hoffen, dass der Ram reicht (Du kriegst ja für einen
Way nicht einfach so die Nodes und für eine Relation die Ways in der
Osmosis-Pipeline).

 Und es geht auch fuer generelle polygone - muss nur jemand bauen. Ich
habe
 nur admin boundarys gebraucht fuer die Strassenlistenauswertung - der
rest
 ist mir erstmal wumpe ...

Ist schon klar. 

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

Re: [Talk-de] Relationsstruktur fuer geografische Einordnung

On Thu, 8 Oct 2009 14:13:02 +0200, Florian Lohoff f...@rfc822.org wrote:
 Wer solche dinge macht - d.h. nicht nur fertige produkte wie sie slippy
 map
 ansieht sollte nunmal in der lage sein sich solches wissen und
faehigkeiten
 anzueignen. Natuerlich waere das schoen wenn die OSMXAPI eine
 Antwortszeit von 100ms haette und jeder das mit Mausischupsi bedienen
 koennte - aber je groesser das planet file wird in desto weitere
 ferne rueckt das. Daher meine ich ja das OSMXAPI ein auslaufmodell ist.

Ahnung warum OSMXAPI nicht skaliert?
Ich hab keine Bitten um Server-Kapazität gesehen,
daran wirds also wohl nicht liegen.

Marcus

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

Re: [Talk-de] TMC-Import startet und braucht eure Hilfe


Auf
http://wiki.openstreetmap.org/wiki/TMC/TMC_Import_Germany/Areas/3600_to_3700
hab ich jetzt zum Testen eine der neu generierten Wiki-Tabellen.

* kein Link auf JOSM mehr
* Link zum RemoteControl-Plugin oben
* neu: Bounding-Box downloads

Was noch kommt:
* Bounding-Box in .osm -Dateien
* irgendwie die ganzen Wiki-Tabellen aktualisieren.
  (Captcha macht Probleme.)

Marcus

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

Re: [Talk-de] TMC Supportanfrage (Re: TMC-Import startet und braucht eure Hilfe)

On Wed, 7 Oct 2009 09:51:46 +0200, Sven Anders s...@anders-hamburg.de
wrote:
 Hallo,
 ich würde gerne mithelfen.
 http://wiki.openstreetmap.org/wiki/DE:TMC/TMC_Import_Germany/Areas 
 
 durchgelesen.
 
 Würde jetzt den Landkreis Harburg (LocationCode 453) vornehmen.
 
 Auf der Wiki Seite steht als Symbol ich solle 
 
 TMC:cid_58:tabcd_1:LocationCode=453 an einen Weg einfügen (icon in der 
 Spalte weg oder Knoten)? Oder an die Relation?

Schnelle Antwort ohne die angegebenen OSM-Elemente
angeschaut zu haben:

Wenn eine Relation welche die Grenz-Abschnitte des Gebietes
enthält existiert, diese Taggen.
Ansonsten, wenn ein Polygon existiert dieses.
Enthaltene andere Gebiete nicht mit dem gleichen Code
taggen, da es ja andere Gebiete sind.


  member type=relation ref=-3 role=contains: 
 TMC:cid_58:tabcd_1:LocationCode=3939 Neu Wulmstorf/
 
 Soll ich dann an die Gemeindegrenze von Neu Wulmstorf auch einen Code
 hängen?

Da diese Gemeinde einen Code hat, kannst du den gerne gleich auch taggen.
Klar. Nur im Wiki nachtragen, damit klar ist was schon gemacht wurde.

Ich fürchte der Begriff Samtgemeinden sagt mir nichts.
 Auch die Gemeinde Wischafen wird erwähnt, für die Samtgemeinde
Oldendorf
 gibt 
 es  allerdings kein TMC Code.

Es muss nicht für jede Gemeinde auch einen TMC-Code geben.
Wenn sie für Verkehrs- oder Katastropgen-meldungen uninteressant ist,
wird es wohl keinen code geben.

Umgekehrt sehen wir aber wunderbar wenn uns Gemeinden fehlen. ;)

Marcus

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

Re: [Talk-de] TMC Supportanfrage (Re: TMC-Import startet und brauchteure Hilfe)

On Wed, 7 Oct 2009 10:12:21 +0200, Mirko Küster webmas...@ts-eastrail.de
wrote:
 Auch die Gemeinde Wischafen wird erwähnt, für die Samtgemeinde
 Oldendorf
 gibt
 es  allerdings kein TMC Code. Naja vielleicht brauchen wir mal eine Wiki
 Seite um solche Dinge zu Sammeln und an die Verwaltung zurück zu
melden.
 
 Kommt noch besser. Im Kyffhäuserkreis wird ein Ort Schönwerder
 erwähnt. 
 Den gibts gleich garnicht. Es könnte Schönewerda gemeint sein. Nur ist
 das 
 seit 10 Jahren Ortsteil von Roßleben und hat seitdem keine eigene Grenze

 mehr. Obendrein passt es aber nicht zum Rest der Orte. Die liegen
nämlich 
 allesamt an Bundesstraßen, Schönewerda an popeligen Landstraßen.
 
 Und ansonsten kann das mit den Admin Grenzen auch nicht so ganz passen. 
 Sondershausen hat eine Administrative Fläche von 200 km. Aber nur in der

 Kernstadt selbst läuft mit der B4 eine wichtige Straße, im Rest gibts
nur
 
 völlig uninteresannte Straßen. Soll der Code wirklich für die riesen
 Fläche 
 gelten oder doch eher da wo er auch Sinn macht?

Gute Frage.

Ich schau gerade noch wie ich die TMC-Areas mit Bounding-Boxen hochladen
kann.
Dann sollte sowas eindeutiger zu sehen sein.
Kann gut sein, dass da mit Gemeindereformen was auseinandergelaufen ist.

Gebiete für Stau-/Unwetter-/Katastrophen-meldungen können durchaus
sehr gross sein. So ein Starkregen wird sich nicht auf einen Ortsteil
beschränken.
Ich hoffe mit den Bounding-Boxes kriegen wir das aufgelöst.


Marcus

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

Re: [Talk-de] TMC Supportanfrage (Re: TMC-Import startet und braucht eure Hilfe)

On Wed, 7 Oct 2009 09:51:46 +0200, Sven Anders s...@anders-hamburg.de
wrote:

Hallo, ich würde gerne mithelfen.
http://wiki.openstreetmap.org/wiki/DE:TMC/TMC_Import_Germany/Areas
durchgelesen. Würde jetzt den Landkreis Harburg (LocationCode 453)
vornehmen. Auf der Wiki Seite steht als Symbol ich solle
TMC:cid_58:tabcd_1:LocationCode=453 an einen Weg einfügen (icon in der
Spalte weg oder Knoten)? Oder an die Relation? 




http://wiki.openstreetmap.org/wiki/TMC/TMC_Import_Germany/Areas/400_to_500
http://wiki.openstreetmap.org/wiki/TMC/TMC_Import_Germany/Areas/500_to_600
http://wiki.openstreetmap.org/wiki/TMC/TMC_Import_Germany/Areas/3900_to_4000
enthalten jetzt Links zu den bounding-boxen.
Ich hoffe das hilft ein wenig.


PS:

Mein Mail-Client spinnt gerade.
Ich hoffe ich bringe nicht alle Thread-Ansichten durcheinander.

Marcus

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

Re: [Talk-de] TMC Supportanfrage (Re: TMC-Import startet und brauchteure Hilfe)

On Wed, 7 Oct 2009 11:12:06 +0200, Mirko Küster webmas...@ts-eastrail.de
wrote:
 Zur Not gibts da wo es nicht mehr passt halt grobe Polygon
 die nur den LocationCode haben. (grob weil die TMC-Daten
 halt extrem grob sind.)
 
 Auf irgendeine sinnvolle und vor allem Dokumentierte Vorhgehensweise
 müssen 
 wir uns schon einigen. Multipolygone mit Wegen ohne Merkmale sind
schonmal 
 potentiell vom Löschfinger bedroht.

Wo wurden jetzt Multipolygone erwähnt? Kann ich grad nicht finden.

 Ebenso wenn man es mit ungeeigneten 
 Eigenschaften grob über andere Polys drüber legt und sich das dann 
 spätestens beim Validator beißt.

Ich fürchte da hab ich gerade den Faden verlohren.
Könntest du genauer beschreiben, was du meinst?


 Stört auch, weswegen man bisher eben keine nicht topo relevante Dinge
ohne
 Bezug zu physischen Informationen über die Daten gelegt hat.

Seid wann haben definierte Gebiete keinen Bezug zu dem physischen
Gebiet was sie beschreiben?

Marcus

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

Re: [Talk-de] TMC-Import startet und braucht eure Hilfe

On Wed, 7 Oct 2009 11:36:39 +0200, André Riedel riedel.an...@gmail.com
wrote:
 Naja, geh auf die Straße und frag wer etwas mit cid_ oder tabcd_
 anfangen kann. Wenn du es menschenlesbar haben möchtest, müsste man
 country und table benutzen.

Nur dass du unter den Namen country und Table diese Nummern eben
nicht in der LCL im Standard-Austausch-Format eines Landes findest.

Wenn man überhaupt etwas mit TMC:* anfangen kann, dann sind einem
eher die offiziellen Namen tabcd und cid geläufig als zufällig gewählte
Umschreibungen.

 Wie auch immer. Es gab mehrfach Gelegenheit alternativen
 im Wiki zu formulieren. Hat keiner, trotz Aufforderung, gemacht.
 
 10 Zeichen sparen um es nicht unlesbarer zu machen finde ich gut.
 Alles weitere kann auf den deutschen und internationalen Wiki-Seiten
 stehen.

Was hats jetzt das Zitat, dass es für deinen Vorschläg mächtig spät ist
mit deiner Vorliebe von kurzen Schlüsseln zu tun?


Marcus

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

Re: [Talk-de] TMC Supportanfrage (Re: TMC-Import startet und brauchteure Hilfe)