Re: [Talk-de] Widersprüche in den Tags für Richtungen - Herkunft

2012-10-13 Thread Jan Tappenbeck 

Am 12.10.2012 17:54, schrieb Tobias Knerr:

Am 12.10.2012 10:06, schrieb Jan Tappenbeck:

ich erfasse gerade einige Richtungen und Ausfahrten und bin dabei über
das Tag "exit_to" gestolpert was auch in den JOSM-Templates hinterlegt
ist als "Ausfahrt nach ..."

Steht das nicht im Widerspruch zu dem Tag "destination" [1] zumal es für
"exit_to" nicht einmal ein Tag im Wiki gibt.


Mir war gar nicht bewusst, dass exit_to existiert, und mich wundert die
Einbindung in den Standardvorlagen von JOSM.

Inhaltlich sieht es wie ein Duplikat von destination aus - nur dass
destination die spurweise Erfassung (u.a. auch für Geradeaus-Spuren) und
die Handhabung von Straßen ohne baulich getrennte Fahrtrichtungen erlaubt.

Gibt es einen Grund, exit_to statt destination zu verwenden?

Tobias



ich vermute das es zu derzeit wo das JOSM-Present erstellt wurde 
destination noch nicht gab und so ist es durch den Anwender unbewußt 
verwendet worden.


Aus meiner Sicht und da gar nicht dokumentiert sollte es vielleicht 
durch einen Bot umgestellt werden und aus JOSM verschwinden.


Wo müßte man das anschieben weiß das einer - muss es woanders diskutiert 
werden?


Gruß Jan :-)



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

Re: [Talk-de] Widersprüche in den Tags für Richtungen ?? - Ursache der Anwendung

2012-10-13 Thread Jan Tappenbeck 

Am 12.10.2012 19:23, schrieb Chris66:

Am 12.10.2012 17:54, schrieb Tobias Knerr:

Am 12.10.2012 10:06, schrieb Jan Tappenbeck:

ich erfasse gerade einige Richtungen und Ausfahrten und bin dabei über
das Tag "exit_to" gestolpert was auch in den JOSM-Templates hinterlegt
ist als "Ausfahrt nach ..."

Steht das nicht im Widerspruch zu dem Tag "destination" [1] zumal es für
"exit_to" nicht einmal ein Tag im Wiki gibt.


Mir war gar nicht bewusst, dass exit_to existiert, und mich wundert die
Einbindung in den Standardvorlagen von JOSM.

Inhaltlich sieht es wie ein Duplikat von destination aus - nur dass
destination die spurweise Erfassung (u.a. auch für Geradeaus-Spuren) und
die Handhabung von Straßen ohne baulich getrennte Fahrtrichtungen erlaubt.

Gibt es einen Grund, exit_to statt destination zu verwenden?

Tobias



Hi,
ich hab es so verstanden, dass exit_to als Node gesetzt werden soll.
taginfo bestätigt diese Vermutung.



Aber vermutlich nur durch die "einfache" Anwendung im JOSM-Present. 
Gezielt hat das bestimmt keiner angewandt.


Gruß Jan :-)



Für Router ist IMHO das (am Way gesetzte) destination-Tag viel sinnvoller.

Chris




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

Re: [Talk-de] IENC-Import

2012-10-13 Thread Walter Nordmann 
hi,

ist schon etwas komisch:

Die Daten könnten hierher stammen:
http://www.fgs.wsv.de/produkte/kartographie/argo_encs/index.html
interessant: http://www.fgs.wsv.de/bezugsbedingungen_preise/index.html

bin mir derzeit auch nicht sicher, ob hier die Spielregeln eingehalten
werden. Zumindest wird ein eigener Account verwendet.

Gruss
walter





--
View this message in context: 
http://gis.19327.n5.nabble.com/IENC-Import-tp5730314p5730332.html
Sent from the Germany mailing list archive at Nabble.com.

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

Re: [Talk-de] IENC-Import

2012-10-13 Thread Walter Nordmann 
http://wiki.openstreetmap.org/wiki/Potential_Datasources  - negativ
http://lists.openstreetmap.org/listinfo/imports ab jan 2012 - negativ
http://news.gmane.org/gmane.comp.gis.openstreetmap.imports ab mai -- negativ
http://wiki.openstreetmap.org/wiki/Import/Catalogue -- negativ

ich würde mal an die internationale liste und an unser forum  rangehen.

Gruss
walter

p.s. ich hab nur den string "ienc" gesucht, aber der müsste doch wohl sicher
drin stehen.



--
View this message in context: 
http://gis.19327.n5.nabble.com/IENC-Import-tp5730314p5730335.html
Sent from the Germany mailing list archive at Nabble.com.

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

Re: [Talk-de] mkgmap und routing

2012-10-13 Thread toc-rox 
Stell doch mal einen Screenshot zum konkreten Problem ein ...

Gruß Klaus



--
View this message in context: 
http://gis.19327.n5.nabble.com/mkgmap-und-routing-tp5730020p5730338.html
Sent from the Germany mailing list archive at Nabble.com.

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

Re: [Talk-de] IENC-Import

2012-10-13 Thread Joachim Kast 
Hallo,

ich würde auf einen Import aus dem OpenSeaMap-Umfeld tippen. Die
erwähnte Preisliste ist inzwischen hinfällig, da die Geodaten des Bundes
nach der Novellierung des Geodatenzugangsgesetzes als OpenData zur
Verfügung stehen.

Die andere Seite sind natürlich die OSM-Regularien für Importe. Ich
schreibe gleich Markus an, der seitens OpenSeaMap den besten Überblick
hat und den "Verantwortlichen" bestimmt kennt.


Grüße
Joachim


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

Re: [Talk-de] IENC-Import

2012-10-13 Thread Falk Zscheile 
Am 13. Oktober 2012 10:57 schrieb Joachim Kast :
>
> ich würde auf einen Import aus dem OpenSeaMap-Umfeld tippen. Die
> erwähnte Preisliste ist inzwischen hinfällig, da die Geodaten des Bundes
> nach der Novellierung des Geodatenzugangsgesetzes als OpenData zur
> Verfügung stehen.
>

Vorsicht, die Novellierung des GeoZG ist, soweit ich das überblicke
zwar beschlossen, aber noch nicht in Kraft getreten. Im Augenblick
gilt daher noch die bisherige (kostenpflichtige) Rechtslage.

Gruß, Falk

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

Re: [Talk-de] mkgmap und routing

2012-10-13 Thread Wolfgang Hinsch 
Hallo,

Am Samstag, den 13.10.2012, 01:37 -0700 schrieb toc-rox:
> Stell doch mal einen Screenshot zum konkreten Problem ein ...
> 

Vielleicht habe ich es unklar ausgedrückt. Die Datei gmapsupp.img wird
erzeugt. Ich kann sie auf die SD-Karte schieben, und das Navi erkennt
sie soweit, dass ich im Menü "Karte auswählen" die Kartenbezeichnung
sehe. Ich habe auch versucht, am Namen oder Kommentar zu drehen und das
wird entsprechend angezeigt.

Mein Problem besteht darin, dass die Karte im Navi nicht im Display
erscheint. Auch dann nicht, wenn ich die Basiskarte deaktiviere.

Ich habe es auch mit den Ausschnitten der Geo-Fabrik getestet. Bremen
wird angezeigt, Hamburg nicht. Dagegen wird ein alter Hamburg-Ausschnitt
sauber angezeigt.

Navi: Garmin Colorado

Die einzige Fehlermeldung, die mkgmap liefert, ist:

SCHWERWIEGEND (RoadNetwork): Bremen.osm: Road (Gustav-Deetjen-Allee,
http://www.openstreetmap.org/browse/way/4766567) contains zero length
arc at http://www.openstreetmap.org/?mlat=53.08714&mlon=8.81771&zoom=17

so um die 100-300 mal (mit verschiedenen Ways). In Bremen wie in
Hamburg, wie bei josm.

Als Screenshot könnte ich nur das leere Display des Colorado posten...

BS: Suse Linux 12.1 aktuell
Linux Hannibal 3.1.10-1.16-desktop #1 SMP PREEMPT Wed Jun 27 05:21:40
UTC 2012 (d016078) x86_64 x86_64 x86_64 GNU/Linux

Java: 
java-1_6_0-openjdk-1.6.0.0_b24.1.11.4-12.1.x86_64
timezone-java-2012f-1.6.1.noarch
libjavascriptcoregtk-1_0-0-1.6.1-2.1.2.x86_64
java-ca-certificates-1-14.12.1.noarch
libjavascriptcoregtk-3_0-0-1.6.1-2.1.2.x86_64
java-1_5_0-gcj-compat-1.5.0.0-120.1.2.x86_64

mkgmap-2105-44.1.noarch

Wenn ich die Karte von  lade,
funktioniert es.

Bisher hatte ich solche Probleme nicht. Etwas ratlos...

Gruß, Wolfgang



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

Re: [Talk-de] mkgmap und routing

2012-10-13 Thread Wolfgang Hinsch 
Update:

Am Samstag, den 13.10.2012, 11:07 +0200 schrieb Wolfgang Hinsch:

... ein Problem, das schon gelöst war. Das lag an den bounds-Zeilen.



Wenn man mal schnell ist  :(

Sorry. 
Hatte das (auch geistig) etwas nach hinten geschoben.


Das Problem beseht weiterhin darin, dass die Karte jetzt zwar korrekt
angezeigt wird, aber nicht routingfähig ist. An dem Punkt bin ich nicht
weiter gekommen.


> 
> Navi: Garmin Colorado
> 
> Die einzige Fehlermeldung, die mkgmap liefert, ist:
> 
> SCHWERWIEGEND (RoadNetwork): Bremen.osm: Road (Gustav-Deetjen-Allee,
> http://www.openstreetmap.org/browse/way/4766567) contains zero length
> arc at http://www.openstreetmap.org/?mlat=53.08714&mlon=8.81771&zoom=17
> 
> so um die 100-300 mal (mit verschiedenen Ways). 

Bei jedem Rechenlauf.

> 
> BS: Suse Linux 12.1 aktuell
> Linux Hannibal 3.1.10-1.16-desktop #1 SMP PREEMPT Wed Jun 27 05:21:40
> UTC 2012 (d016078) x86_64 x86_64 x86_64 GNU/Linux
> 
> Java: 
> java-1_6_0-openjdk-1.6.0.0_b24.1.11.4-12.1.x86_64
> timezone-java-2012f-1.6.1.noarch
> libjavascriptcoregtk-1_0-0-1.6.1-2.1.2.x86_64
> java-ca-certificates-1-14.12.1.noarch
> libjavascriptcoregtk-3_0-0-1.6.1-2.1.2.x86_64
> java-1_5_0-gcj-compat-1.5.0.0-120.1.2.x86_64
> 
> mkgmap-2105-44.1.noarch
> 
> Wenn ich die Karte von  lade,
> funktioniert es.
> 

Gruß und nochmal sorry,

Wolfgang



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

Re: [Talk-de] IENC-Import

2012-10-13 Thread Joachim Kast 
Mir ist bekannt, dass zwischen WSV und OpenSeaMap seit einiger Zeit enge
Kontakte bestehen und Gedaten zur Nutzung für OSM-Zwecke unter Verzicht
auf Kostenerstattung von der Behörde bereitgestellt wurden.

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

Re: [Talk-de] IENC-Import

2012-10-13 Thread Frederik Ramm 

Hi,

On 13.10.2012 03:33, Michael Bemmerl wrote:

weiß jemand hier was es mit dem Benutzer IENC-Import [1] auf sich hat?
Leider ist auf der Benutzer-Seite keine Beschreibung angegeben und im
Wiki findet sich auch nichts.


http://www.openstreetmap.org/user_blocks/265

Bye
Frederik

--
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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

Re: [Talk-de] IENC-Import

2012-10-13 Thread Walter Nordmann 
wäre ja auch ok, weil gebrauchen kann man die Sachen wohl schon.

nur: wegen der "Spielregeln" bist du ja schon dran
aber: das eigentliche technische Problem der doppelten Nodes, das Michael
zum Eröffnen dieses Threads bewogen hat, ist ja auch noch vorhanden. Das
sieht doch ein wenig nach unsauberer Arbeit aus.

Gruss
walter



--
View this message in context: 
http://gis.19327.n5.nabble.com/IENC-Import-tp5730314p5730351.html
Sent from the Germany mailing list archive at Nabble.com.

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

Re: [Talk-de] IENC-Import

2012-10-13 Thread Peter Wendorff 

Am 13.10.2012 11:18, schrieb Joachim Kast:

Mir ist bekannt, dass zwischen WSV und OpenSeaMap seit einiger Zeit enge
Kontakte bestehen und Gedaten zur Nutzung für OSM-Zwecke unter Verzicht
auf Kostenerstattung von der Behörde bereitgestellt wurden.
Das klingt gut, sollte aber IMHO auch dokumentiert werden, und zwar mehr 
noch als alle anderen OpenSeaMap-Tags zentral im Wiki - in diesem Fall 
verlinkt auch vom entsprechenden Import-Account.
Ich finde, gerade bei Datenquellen, die auf den ersten Blick sogar eine 
widersprüchliche Lizenz auffinden lassen (im Gegensatz zu Quellen, bei 
denen man schlicht keine Information öffentlich findet), ist das 
ordentliche Dokumentieren der Erlaubnis im Wiki ein Muss.


Gruß
Peter

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

Re: [Talk-de] IENC-Import

2012-10-13 Thread Frederik Ramm 

Hallo,

On 13.10.2012 11:33, Walter Nordmann wrote:

aber: das eigentliche technische Problem der doppelten Nodes, das Michael
zum Eröffnen dieses Threads bewogen hat, ist ja auch noch vorhanden. Das
sieht doch ein wenig nach unsauberer Arbeit aus.


Genau dafuer sind die "Spielregeln" ja da - dass Dritte *vor* Beginn 
eines Imports einen Blick auf die Datenquellen und die 
Konvertierungsskripte werfen koennen und auf Fehler aufmerksam machen.


Bye
Frederik

--
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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

Re: [Talk-de] mkgmap und routing

2012-10-13 Thread Steffen Wolf 
Hallo Wolfgang Hinsch,

> Die einzige Fehlermeldung, die mkgmap liefert, ist:

> SCHWERWIEGEND (RoadNetwork): Bremen.osm: Road (Gustav-Deetjen-Allee,
> http://www.openstreetmap.org/browse/way/4766567) contains zero length
> arc at http://www.openstreetmap.org/?mlat=53.08714&mlon=8.81771&zoom=17

> so um die 100-300 mal (mit verschiedenen Ways). In Bremen wie in
> Hamburg, wie bei josm.

Das ist normal. Viele Strassen sind derart genau gemappt, dass dem
mkgmap der Abstand zwischen zwei Knoten zu klein wird (wohl noch
abhaengig von der Zoom-Stufe). Dann warnt er halt.


Zum Routing-Problem kann ich aber nichts sagen, dann

> mkgmap-2105-44.1.noarch

ich nutze noch 1905.

Gruss,
 Steffen
-- 
That's a battery staple.
Correct!
 [xkcd 936]

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

Re: [Talk-de] mkgmap und routing

2012-10-13 Thread Chris66 
Am 13.10.2012 11:18, schrieb Wolfgang Hinsch:

>> Die einzige Fehlermeldung, die mkgmap liefert, ist:
>>
>> SCHWERWIEGEND (RoadNetwork): Bremen.osm: Road (Gustav-Deetjen-Allee,
>> http://www.openstreetmap.org/browse/way/4766567) contains zero length
>> arc at http://www.openstreetmap.org/?mlat=53.08714&mlon=8.81771&zoom=17

Versuch mal --remove-short-arcs oder --remove-short-arcs=3

Wenn Du keine oder falsche bounds drin hast, musst Du
--ignore-osm-bounds setzen.

Chris




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

Re: [Talk-de] mkgmap und routing

2012-10-13 Thread Bernhard Weiskopf 
> contains zero length arc at 
> http://www.openstreetmap.org/?mlat=53.08714&mlon=8.81771&zoom=17


Das sollte man auch mal umzeichnen: Die Service-Road-Anbindungen an die
Gustav-Deetjen-Allee liegen weniger 1 m nebeneinander, da ist mit Sicherheit
keine bauliche Trennung mehr dazwischen. 

Vielleicht wird die Koordinaten-Auflösung des Navis hier unterschritten,
dass dann zwei Knotenpunkte die gleichen Koordinaten erhalten. 

Zu dichte Knotenpunkte ohne Abzweig kann das Navi einfach verwerfen, hier
sind dann aber zwei Abzweige dran und das Navi kann dann den Winkel
dazwischen (geradeaus oder abbiegen zum nächsten Knoten) nicht mehr
bestimmen (interne Division durch Null).

Bernhard




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

[Talk-de] "Relationen sind keine Kategorien" aus der Sicht des Mappers

2012-10-13 Thread Tirkon 
Ursprüngliches Subjekt: Mal wieder eine Gruppierung mittels
Relation...

Frederik Ramm  wrote:

>On 11.10.2012 13:04, Manuel Reimer wrote:
>> http://www.openstreetmap.org/browse/relation/1612032
>> Meiner Ansicht nach kann das auch wunderbar via Overpass-API gemacht werden. 
>> Was
>> meint ihr dazu?
>
>Ich meine dazu: Es waere unhoeflich, die Relation *sofort* zu loeschen; 
>man sollte dem Ersteller erst eine Nachricht schicken und ihm erklaeren, 
>warum man sie loeschen wird ;)

Technisch solltet ihr mit einer solchen Löschung recht haben. Es gibt
da allerdings ein grundsätzliches Problem mit diesen Sammelrelationen.
"Relationen sind keine Kategorien" ist den meisten Mappern nur
schwerlich vermittelbar.
http://wiki.openstreetmap.org/wiki/DE:Relationen/Relationen_sind_keine_Kategorien

ZitaT daraus: 
>Um alle Fußwege in Sachsen zu erhalten, genügt es, die Grenze von Sachsen 
>anzugeben und alle Fußwege können problemlos automatisch aus der Datenbank 
>extrahiert werden.

Der Pferdefuß an der Sache: Nur eine kleine Minderheit von Mappern ist
in der Lage, APIs zu nutzen. Für die gewaltige Mehrheit von Otto
Normalmappern - und das sind nicht nur Wikipedianer - sind Relationen
das einzige Mittel hierfür. Sie rufen die Relation auf und haben damit
alle gewünschten Member. Für sie erscheint die Sache so, als ob sie
ausgeschlossen werden, aber kommerzielle Unternehmen mit
entsprechendem Sachverstand die Datenbank nutzen können. 

Daten liefern zu sollen aber sie selbst nicht nutzen zu können,
demotiviert. Dies gilt umso mehr, wenn das hierfür funktionierende
Instrument der Relation schon existert aber dennoch nicht genutzt
werden darf. Natürlich trifft das nicht nur für diese
"Kategorien"-Relationen zu. 

Sprich: Erst !!nutzbare!! Features machen das Mappen auch für
Nichtprogrammierer attraktiv.


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