You are not logged in.

#1 2013-09-28 08:41:56

toc-rox
Member
From: Münster
Registered: 2011-07-20
Posts: 2,340
Website

Wer könnte einige Problem-Polygone prüfen?

WARNING: outer way of multi polygon is not a polygon, skipping it
WARNING: cannot create geometry for way

Compiliert man eine Karte mit dem Mapsforge mapwriter so erhält man für eine Reihe von (Multi-)Polygonen die vorgenannten Meldungen. Die Objekte werden verworfen und für jedes Objekt wird eine Debugdatei erzeugt. Ich hatte mir mal einige dieser Objekte angesehen, konnte aber keine offensichtlichen Fehler finden. Auch die Identifizierung der zugrundeliegenden OSM-Objekte gestaltet sich schwierig, da die Debugdateien nur die Koordinaten des betreffenden Objektes enthalten.

Beispiel: LINEARRING (8.742017 54.307891, 8.745056 54.319278, ... 8.742017 54.307891)
Das Beispiel führt mich irgendwie zur Relation 1443899 ... da scheint sich etwas zu kreuzen.

Frage: Wie könnte man am einfachsten von den Koordinaten auf das OSM-Objekt schließen?

Gruß Klaus

EDIT: Titel geändert

Last edited by toc-rox (2013-12-21 14:10:21)

Offline

#2 2013-09-28 09:06:19

couchmapper
Member
Registered: 2013-02-17
Posts: 462

Re: Wer könnte einige Problem-Polygone prüfen?

Die in der ersten Zeile aufgeführte Warnung sollte eigentlich gemäß folgendem  Code bereits die Way id enthalten. Das sollte die Fehleranalyse vereinfachen.

http://code.google.com/p/mapsforge/sour … s.java#350

Offline

#3 2013-09-28 09:25:48

toc-rox
Member
From: Münster
Registered: 2011-07-20
Posts: 2,340
Website

Re: Wer könnte einige Problem-Polygone prüfen?

Ausgegeben werden m.E. interne IDs ... eine Korrelation mit OSM-IDs ist mir noch nicht gelungen.
Die vollständigen Meldungen sehen dann so aus:

WARNING: outer way of multi polygon is not a polygon, skipping it: 1202782060
WARNING: cannot create geometry for way with id: 1202781353

Gruß Klaus

Offline

#4 2013-09-28 09:34:36

EvanE
Member
Registered: 2009-11-30
Posts: 5,716

Re: Wer könnte einige Problem-Polygone prüfen?

toc-rox wrote:

WARNING: outer way of multi polygon is not a polygon, skipping it
WARNING: cannot create geometry for way

Compiliert man eine Karte mit dem Mapsforge mapwriter so erhält man für eine Reihe von (Multi-)Polygonen die vorgenannten Meldungen. Die Objekte werden verworfen und für jedes Objekt wird eine Debugdatei erzeugt. Ich hatte mir mal einige dieser Objekte angesehen, konnte aber keine offensichtlichen Fehler finden. Auch die Identifizierung der zugrundeliegenden OSM-Objekte gestaltet sich schwierig, da die Debugdateien nur die Koordinaten des betreffenden Objektes enthalten.

Beispiel: LINEARRING (8.742017 54.307891, 8.745056 54.319278, ... 8.742017 54.307891)
Das Beispiel führt mich irgendwie zur Relation 1443899 ... da scheint sich etwas zu kreuzen.

Frage: Wie könnte man am einfachsten von den Koordinaten auf das OSM-Objekt schließen?

Hallo  Klaus

Am Besten wäre es, wenn der Mapwriter dazuschreiben würde, welches OSM-Objekt diese Fehlermeldung verursacht hat. Wenn das nicht geht, z.B. weil diese Information beim entsprechenden Verarbeitungsschritt nicht mehr vorhanden ist, dann hilft z.B. JOSM. Dort kannst du die Koordinaten von zwei Punkten als Bounding-Box zum Download angeben.

Wenn du nun zwei benachbarte Punkte auswählst, bekommst du eine BBox in der eine diagonale Linie liegt. Eine der Relationen, die diese Linie verwenden muss der Übeltäter sein. Du solltest dann die Relationen komplett runterladen, um sie dir anzusehen.
Wie du vermutest hast, geht es um die PLZ-Relation 1.443.899 (25881 Tating), die aus zwei getrennten Outer mit einem gemeinsamen Punkt besteht. Es ist der Punkt mit den Koordinaten 54.319278, 8.6900598 und der Objekt-ID 1.123.423.767. JOSM kommt mit der Überschneidung klar, MapWriter offensichtlich nicht.

Im konkreten Fall gibt es diesen gemeinsamen (Kreuzungs-)Punkt nur bei der Postleitzahl (25881 Tating). Die Admin-Grenzen sind jeweils disjunkt, überschneiden sich also nicht.

Ganz schön umständlich
Edbert (EvanE)

Offline

#5 2013-09-28 10:26:07

Oli-Wan
Member
From: NRW
Registered: 2010-09-14
Posts: 2,814

Re: Wer könnte einige Problem-Polygone prüfen?

EvanE wrote:

Am Besten wäre es, wenn der Mapwriter dazuschreiben würde, welches OSM-Objekt diese Fehlermeldung verursacht hat. Wenn das nicht geht, z.B. weil diese Information beim entsprechenden Verarbeitungsschritt nicht mehr vorhanden ist, ...

Das dürfte in der Tat der Fall sein. Augenscheinlich werden alle äußeren Wege (einer oder mehrere) zu einem neuen "TDWay" zusammengesetzt. Die TDWay-Objekte werden bei ihrer Erzeugung mit einer fortlaufenden Nummer versehen, die mit der Nummer des ursprünglichen Wegs nichts zu tun hat.

outerWay = new TDWay(++BaseTileBasedDataProcessor.this.maxWayID, relation.getLayer(),
                     relation.getName(), relation.getHouseNumber(), relation.getRef(), relation.getTags(),
                     shape, waynodes);

Man könnte wie folgt ansetzen: die TDWay-Klasse dahingehend erweitern, daß sie die Nummern der Wege speichert, aus denen sie erzeugt wird; im Fehlerfall diese ausgeben. Das wird toc-rox allerdings selbst machen müssen, da Mapsforge offenbar nicht mehr gepflegt wird.


No animals were harmed in the writing of this posting.

Offline

#6 2013-09-29 12:43:36

toc-rox
Member
From: Münster
Registered: 2011-07-20
Posts: 2,340
Website

Re: Wer könnte einige Problem-Polygone prüfen?

Da ich an den Sourcen nichts ändern möchte, werde ich die Variante via JOSM verwenden. Danke für eure Hinweise.

Gruß Klaus

PS: Die Mapsforge-Entwickler arbeiten seit längerem an der Version 0.4, die dann auch ein (plattformunabhängiges) Swing-Interface beinhaltet.

Offline

#7 2013-10-13 17:27:08

toc-rox
Member
From: Münster
Registered: 2011-07-20
Posts: 2,340
Website

Re: Wer könnte einige Problem-Polygone prüfen?

Hätte da jemand Interesse sich der Problemfälle anzunehmen (mir wird das etwas zu viel). Aktuell (10.10.2013) ist z.B. der Wald um den Brocken (Harz) verloren gegangen.

Gruß Klaus

Offline

#8 2013-12-21 14:09:05

toc-rox
Member
From: Münster
Registered: 2011-07-20
Posts: 2,340
Website

Re: Wer könnte einige Problem-Polygone prüfen?

Beim letzten Build der Freizeitkarte-Android sind wieder einige Problem-Polygone aufgefallen. Vielleicht hat ja jemand Lust (und Zeit) sich das anzusehen ...

What does Mapsforge cause to fail (von ChristianK):
- intersections (crossing lines, touching lines, 2 points at the same position)
- self backing up lines (loops) = extreme hard to find, a common issue with self snapping editors like Potlach and ID.
Self backing up lines mean a line returning by 180° to its previous point = A-B-C-B-….

Die Daten finden sich hier: https://dl.dropboxusercontent.com/u/167 … ugFile.zip

Gruß Klaus

Offline

#9 2013-12-22 10:16:09

Weide
Member
Registered: 2009-04-05
Posts: 1,491

Re: Wer könnte einige Problem-Polygone prüfen?

Hi,

ich hab mir mal den fünftletzten Eintrag (Way 158746691) angesehen:

toc-rox wrote:

What does Mapsforge cause to fail (von ChristianK):
- intersections (crossing lines, touching lines, 2 points at the same position)
- self backing up lines (loops) = extreme hard to find, a common issue with self snapping editors like Potlach and ID.
Self backing up lines mean a line returning by 180° to its previous point = A-B-C-B-….

Keines dieser Probleme liegt da vor.

Aber vielleicht liefert dieses MP 2125165 Hinweise. Es besteht aus 33 jeweils in sich geschlossenen "outer", einem zweiteiligen "outer" und nur zwei "inner".

Interessant ist jetzt, dass nur zwei der 34 "outer" in der Liste stehen: Die beiden sind in sich geschlossen und enthalten jeweils ein inner. Da wäre jetzt also die Frage, ob Mapsforge Probleme mit der Zuordnung von "inner" zu "outer" hat.

Weide

PS:

self backing up lines (loops) = extreme hard to find

Ein zeitweiliges Hinzufügen von waterway=river lässt eine Prüfung durch JOSM zu.

Last edited by Weide (2013-12-22 10:17:35)

Offline

#10 2013-12-22 11:07:01

malenki
Member
Registered: 2008-09-07
Posts: 636

Re: Wer könnte einige Problem-Polygone prüfen?

Zum einfacheren Debuggen habe ich mit folgendem Befehl das jeweils erste Koordinatenpaar in einen OSM-Link umgewandelt:

for i in DebugOuterWay_*; do echo "http://www.osm.org/#map=18/"$(less "$i"| awk -F ", " '{print $2 }'| awk '{print $2"/"$1}'); done|nl -n rz| sed s/0000//g

Resultat:

Edit hat die vertauschten Koordinaten umgedreht. (Wenn jemand Hilfe wünscht, sollte er potentiellen Helfern mögliche Stolpersteine aus dem Weg räumen...)
Die zweite Edit hat Duplikate aufgeräumt und so die Anzahl der Links von 46 auf 22 reduziert.

PS: Zwischen 01 und 10 fand ich nur bei Nummer 6 ein Loch in einer Grenze. Den Rest überlasse ich anderen Arbeitswütigen.

Last edited by malenki (2013-12-22 11:42:23)

Offline

#11 2014-09-24 11:52:54

wambacher
Member
From: Schlangenbad/Wambach, Germany
Registered: 2009-12-16
Posts: 16,755
Website

Re: Wer könnte einige Problem-Polygone prüfen?

toc-rox wrote:

PS: Die Mapsforge-Entwickler arbeiten seit längerem an der Version 0.4, die dann auch ein (plattformunabhängiges) Swing-Interface beinhaltet.

Hi Klaus,

da es (bei dir) wohl immer noch Probleme dieser Art gibt: Welche Version setzt du aktuell ein und was hat sich geändert?

25881 Tating ist offensichtlich inzwischen sauber und sollte keine Probleme mehr machen.

Gruss
walter

Offline

#12 2014-09-24 12:31:41

wambacher
Member
From: Schlangenbad/Wambach, Germany
Registered: 2009-12-16
Posts: 16,755
Website

Re: Wer könnte einige Problem-Polygone prüfen?

Hi,

nach einer längeren Mail-Kommunikation mit Klaus (die ich lieber im Forum geführt hätte), versuch ich mal die Problematik ein wenig zusammenzufassen:

Statement: Wir haben "komische" Daten in der OSM-Datenbank. Punkt.

Diese stammen in der Regel von schlampigen Editoren (sowohl Programmen als auch Menschen) und sind u.A.

- sich überschneidende Linien
- sich berührende Linien
- doppelte Punkte
- a-b-c-b-d Linien

Zudem Multipolygone, die nicht sauber sind. (inner/outer falsch, Missachtung des OGC-Standards)

Es gibt nun die verschiedensten Programme, die in irgend einer Form diese Rohdaten verwenden (müssen):

- osm2pgsql baut daraus eine lokale DB zum Rendern oder auch für Nominatim
- OverPass liefert vorverarbeitete OSM-Daten für den Anwender
- Die API liefert alle unveränderten Daten nach Bedarf
- Die Editoren arbeiten natürlich mit der API
- und wohl auch MapsForge

Jede dieser Anwendungen muß sich nun mit den offensichtlichen Fehlern herumschlagen:

- osm2pgsql (mein Favorit) versucht, alles Mögliche zu korrigieren oder ignoriert manche Daten einfach - und das ohne den geringsten Kommentar.
- was die OverPass ausbügelt, ist mir nicht bekannt
- die API macht nix
- die Editoren bekommen den Schrott halt so geliefert, wie er ist; Josm "motzt" allerdings vor dem Hochladen über manche Fehler.
- MapsForge "motzt" ohne vernünftige Hintergrundinformationen und ignoriert die falschen Daten einfach.

u.s.w.

Aus diesem Grunde verstehe ich (inzwischen) die Frage von Klaus, ob man das Übel nicht endlich mal an der Wurzel anfassen kann.

Gibt es von euch dazu irgendwelche Ideen? Mir ist da Keepright und auch der OSMI durch den Kopf geschossen.
Irgendwie fehlt da noch Feedback von den Anwendungen/Konvertern, der auch wirklich in die OSM-DB einfließt.

Frage: Erstellt KeepRight eigentlich Reports, die der Betreuer uns zur Verfügung stellen kann? Eine Liste bringt oft mehr als "Geh mal in deine Ecke und räume da auf"

Ich mach mir mal Gedanken, was ich aus meiner DB rauskitzeln kann. Für die DB-Profies: Die Rohdaten stehen ja auch in der lokalen DB drin, nicht nur das von osm2pgsql bereinigte Zeug.

Gruss
walter

edit: Tüpo

Last edited by wambacher (2014-09-24 12:34:45)

Offline

#13 2014-09-24 14:10:29

Netzwolf
Member
Registered: 2008-04-01
Posts: 1,665
Website

Re: Wer könnte einige Problem-Polygone prüfen?

Nahmd,

saubere Lösung: der OSM-DB-Server setzt Integritätsbedingungen durch: verweigert das Upload defekter Daten → der Leidensdruck “das Heulen und Zähneknirschen” ist bei den Erstellern der defekten Daten — bei denen, die auch was dran tun können — und nicht bei den Auswertern.

Banales Beispiel: bei type=multipolygon müssen alle Ways als Rolle inner oder outer tragen, die Outer müssen vorne stehen, und die Ways zu jedem Teilring fortlaufend in der Relation stehen. Ist für einen Editor einfach zu gewährleisten, und für den OSM-DB-Server mit Minimalaufwand nachzurechnen.

Wird aber nicht passieren. Schon weil der Id dafür angepasst werden müsste.

Gruß Wolf


Nach dem Umzug des Forums in eine von HOT-Angestellten genudgete Bällchenbad-Community, die infantile Befindlichkeiten wichtig nimmt, werde ich auch nicht mehr sporadisch vorbeischauen. Fragen zu meinen Beiträgen also bitte per Mail oder anonym via Twitter-DM.

Offline

#14 2014-09-24 18:29:51

toc-rox
Member
From: Münster
Registered: 2011-07-20
Posts: 2,340
Website

Re: Wer könnte einige Problem-Polygone prüfen?

Vielleicht hilft es ja weiter ... diese Polygone wurden beim Build (Mapsforge) der Karte für Niedersachen (geofabrik-Extrakt vom 24.09.2014) ausgeworfen:

-rw-r--r-- 1 kto kto  28K Sep 24 19:04 DebugOuterWay_1200045271.txt
-rw-r--r-- 1 kto kto  25K Sep 24 19:04 DebugOuterWay_1200047706.txt
-rw-r--r-- 1 kto kto 9.3K Sep 24 19:04 DebugOuterWay_1200047707.txt
-rw-r--r-- 1 kto kto 1.5K Sep 24 19:04 DebugOuterWay_29413042.txt

Link: https://dl.dropboxusercontent.com/u/167 … achsen.zip

Angesehen habe ich mir die Daten aber noch nicht.

Gruß Klaus

Nachtrag: Hier noch die wenig ausagekräftigen Warning des Mapwriters:

WARNING: outer way of multi polygon is not a polygon, skipping it: 1200045271
WARNING: outer way of multi polygon is not a polygon, skipping it: 1200047707
WARNING: outer way of multi polygon is not a polygon, skipping it: 1200047706
WARNING: outer way of multi polygon is not a polygon, skipping it: 29413042

Last edited by toc-rox (2014-09-24 18:32:47)

Offline

#15 2014-09-24 19:05:14

wambacher
Member
From: Schlangenbad/Wambach, Germany
Registered: 2009-12-16
Posts: 16,755
Website

Re: Wer könnte einige Problem-Polygone prüfen?

Netzwolf wrote:

Nahmd,

saubere Lösung: der OSM-DB-Server setzt Integritätsbedingungen durch: verweigert das Upload defekter Daten → der Leidensdruck “das Heulen und Zähneknirschen” ist bei den Erstellern der defekten Daten — bei denen, die auch was dran tun können — und nicht bei den Auswertern.

Eigentlich der richtige Weg, aber wohl nur bei banalen Fehlern bei einzelnen Objekten machbar. Sobald es um diejenigen Geometrien geht, bei denen mehrere OSM-Objekte gleichzeitig beteiligt sind, muß das die Performance beim Update massiv runterziehen.

Banales Beispiel: bei type=multipolygon müssen alle Ways als Rolle inner oder outer tragen, die Outer müssen vorne stehen, und die Ways zu jedem Teilring fortlaufend in der Relation stehen. Ist für einen Editor einfach zu gewährleisten, und für den OSM-DB-Server mit Minimalaufwand nachzurechnen.

Banal aber ziemlich falsch:

Inner/Outer an fast allen Ways sind derzeit wegen bestehender Konventionen zwingend, obwohl diese Rollen zumindest von osm2pgsql total ignoriert werden, da sich das bei der Konvertierung in ein OGC-Objekt automatisch ergibt - rein aus der Geometrie.
Zudem gibt es admin_centre, die aus einem Building bestehen und somit ein geschlossener Way sind (genau so wie ein Mini-Inner)
Und die Reihenfolge der Member innerhallb einer Relation sind ebenfalls total unwichtig bis auf Buslinien - aber das ist ein anderes Thema.

Hast halt ein unpassendes Beispiel genommen sad

Gruss
walter

Offline

#16 2014-09-24 19:09:02

wambacher
Member
From: Schlangenbad/Wambach, Germany
Registered: 2009-12-16
Posts: 16,755
Website

Re: Wer könnte einige Problem-Polygone prüfen?

toc-rox wrote:

Vielleicht hilft es ja weiter ... diese Polygone wurden beim Build (Mapsforge) der Karte für Niedersachen (geofabrik-Extrakt vom 24.09.2014) ausgeworfen:

-rw-r--r-- 1 kto kto  28K Sep 24 19:04 DebugOuterWay_1200045271.txt
-rw-r--r-- 1 kto kto  25K Sep 24 19:04 DebugOuterWay_1200047706.txt
-rw-r--r-- 1 kto kto 9.3K Sep 24 19:04 DebugOuterWay_1200047707.txt
-rw-r--r-- 1 kto kto 1.5K Sep 24 19:04 DebugOuterWay_29413042.txt

Link: https://dl.dropboxusercontent.com/u/167 … achsen.zip

Nachtrag: Hier noch die wenig ausagekräftigen Warning des Mapwriters:

WARNING: outer way of multi polygon is not a polygon, skipping it: 1200045271
WARNING: outer way of multi polygon is not a polygon, skipping it: 1200047707
WARNING: outer way of multi polygon is not a polygon, skipping it: 1200047706
WARNING: outer way of multi polygon is not a polygon, skipping it: 29413042

Sorry, daß ich nerve: Welche Version und was sagen die Autoren dazu? In der 4.x wurde doch Besserung versprochen.

Schau'n mer mal.

Gruss
walter

Offline

#17 2014-09-24 19:14:30

toc-rox
Member
From: Münster
Registered: 2011-07-20
Posts: 2,340
Website

Re: Wer könnte einige Problem-Polygone prüfen?

wambacher wrote:

Welche Version und was sagen die Autoren dazu? In der 4.x wurde doch Besserung versprochen.

Für den Kartenbuild wurde der Mapwriter in einer Version 0.3.1 genutzt. In der Version 0.4 des Mapwriters wurden m.W. nur technische Änderungen vorgenommen, damit das Plugin mit der aktuellen osmosis-Version klar kommt. Fachlich wurde, soweit ich weiss, nichts geändert. Hast du da anderes gelesen?

Gruß Klaus

Offline

#18 2014-09-24 20:03:34

wambacher
Member
From: Schlangenbad/Wambach, Germany
Registered: 2009-12-16
Posts: 16,755
Website

Re: Wer könnte einige Problem-Polygone prüfen?

so, ich hab mit mal  DebugOuterWay_29413042.txt angesehen, da es das kürzeste File war.
Mit eine wenig Editieren hab ich daraus ein Poly-File gemacht und dieses in Josm geladen:

Siehe, es ist Juist.

tn_juist_poly1.png

Das die Grenze beschreibende Multipolygon ist die Relation https://www.openstreetmap.org/relation/897895. Diese enthält nur den Way https://www.openstreetmap.org/way/29413042 und der ist total in Ordnung - sagt zumindest der Josm-Validator.

Meine DB stimmt da zu:

select osm_id,ST_Summary(way),ST_IsSimple(way), ST_IsValid(way) 
  from planet_osm_line
 where osm_id=29413042;

  osm_id  |          st_summary          | st_issimple | st_isvalid 
----------+------------------------------+-------------+------------
 29413042 | LineString[b] with 73 points | t           | t

Da diese Daten bereits durch die "Hände" von osm2pgsql gegangen sind, schaue ich mit jetzt noch die Rohdaten an.

Warum um Himmels willen zickt Mapsforge da rum? Frage bitte mit diesen Infos den Autor.

Gruss
walter

Nachtrag: Eine Möglichkeit wäre noch, daß mapsForge eine der anderen Relationen, die diesen Way enthalten, nicht gefällt. Aber dazu soll der Autor (endlich) was sagen.

Offline

#19 2014-09-24 20:10:09

wambacher
Member
From: Schlangenbad/Wambach, Germany
Registered: 2009-12-16
Posts: 16,755
Website

Re: Wer könnte einige Problem-Polygone prüfen?

toc-rox wrote:

Fachlich wurde, soweit ich weiss, nichts geändert. Hast du da anderes gelesen?

Nö, nur das es eine neue Version gibt (4.3 ?)

also benutze die und danach reden wir weiter.

Ich verstehe langsam nicht, wieso du die Mapsforge-Leute da nicht mehr einspannst. Christoph mag ja ein liebes Kerlchen sein, aber alles auf die "schlechten OSM-Daten" zu schieben ohne vernünftigen Feedback zu lifern, ist mMn nicht die feine Art.

Gruss
walter

ps: Nur zu meiner Sicherheit: MapWriter ist doch wohl integraler Bestandteil von MapsForge? Oder liege ich daneben?

EDIT: Jo, scheint Bestandteil zu sein. Nur: Download des Plugins funktioniert nicht (File not found). Klasse! auf einer anderen Seite funzt es.

Nachtrag:
hab MapWriter 0.4 am Laufen. Verarbeitet Niedersachsen in 3-4 Minuten ohne Fehler und erzeugt kein debug-file, trotz Option. Und nu?

Last edited by wambacher (2014-09-24 22:10:33)

Offline

#20 2014-09-25 17:06:09

chkr
Member
Registered: 2012-02-06
Posts: 235

Re: Wer könnte einige Problem-Polygone prüfen?

Moin Walter,

wambacher wrote:

hab MapWriter 0.4 am Laufen. Verarbeitet Niedersachsen in 3-4 Minuten ohne Fehler und erzeugt kein debug-file, trotz Option. Und nu?

hast du deine Karte auch mal in Küstennähe angeschaut?

Gruss Christian

Offline

#21 2014-09-25 19:12:01

wambacher
Member
From: Schlangenbad/Wambach, Germany
Registered: 2009-12-16
Posts: 16,755
Website

Re: Wer könnte einige Problem-Polygone prüfen?

chkr wrote:

Moin Walter,

wambacher wrote:

hab MapWriter 0.4 am Laufen. Verarbeitet Niedersachsen in 3-4 Minuten ohne Fehler und erzeugt kein debug-file, trotz Option. Und nu?

hast du deine Karte auch mal in Küstennähe angeschaut?

Nein, sorry, aber ich kenne und brauche das Zeug garnicht in der Praxis.

Ich habe nur den MapWriter installiert und bekomme keinerlei Fehlermeldungen beim Konvertieren von Niedersachsen. Einen Debug-Log krieg ich auch nicht.

tox-rox hält sich auch bedeckt und ohne mindesten einen nachvollziehbaren Fehler bei der Konvertierung der OSM-Daten kann ich  nichts machen. Auf einer Karte, die ich nicht habe, nach komischen Stellen zu suchen und dann zu raten, woran das wohl liegen könnte, ist nicht mein Ding.

Wie soll ich einen Validator schreiben, wenn ich keine "falschen" Daten habe? Wäre wirklich ein interessantes und auch nützliches Projekt für mich  und OSM sad

Gruss
walter

mein Script:

#!/bin/bash
#
#set -x
#
cd /home/walter/osm/MapWriter
date

OSMOSIS=/opt/install/osmosis-latest/bin/osmosis

JAVACMD_OPTIONS="-Xmx4G"
export JAVACMD_OPTIONS

$OSMOSIS \
        --read-pbf file=/data4/import/tmp/niedersachsen-latest.osm.pbf \
	--mapfile-writer file=niedersachsen-latest.map \
                         debug-file=true

Last edited by wambacher (2014-09-25 19:14:30)

Offline

#22 2014-09-25 19:26:03

chkr
Member
Registered: 2012-02-06
Posts: 235

Re: Wer könnte einige Problem-Polygone prüfen?

Moin Walter,

wambacher wrote:

Nein, sorry, aber ich kenne und brauche das Zeug garnicht in der Praxis.

Ich habe nur den MapWriter installiert und bekomme keinerlei Fehlermeldungen beim Konvertieren von Niedersachsen. Einen Debug-Log krieg ich auch nicht.

... hätt' ja sein können. So wissen wir jetzt zwar, dass es keine Debug-Meldung gab, aber ob die Insel kommentarlos verarbeit oder auch noch die Debug-Meldungen-ausgeben Routine kaputt ist, wissen wir nicht.

Gruss Christian

Offline

#23 2014-09-25 19:30:54

couchmapper
Member
Registered: 2013-02-17
Posts: 462

Re: Wer könnte einige Problem-Polygone prüfen?

Das Ticket hier riecht sehr nach eurem Problem: https://code.google.com/p/mapsforge/iss … ail?id=431

OK, I have analyzed the situation further and printed the offending polygon. It looks like you check if the geometry is an instance of a Polygon, but forgot that if there is only a single linear ring as the outer boundary this check fails.

(Hervorhebung von mir)

Last edited by couchmapper (2014-09-25 19:36:20)

Offline

#24 2014-09-25 19:34:07

wambacher
Member
From: Schlangenbad/Wambach, Germany
Registered: 2009-12-16
Posts: 16,755
Website

Re: Wer könnte einige Problem-Polygone prüfen?

chkr wrote:

Moin Walter,

wambacher wrote:

Nein, sorry, aber ich kenne und brauche das Zeug garnicht in der Praxis.

Ich habe nur den MapWriter installiert und bekomme keinerlei Fehlermeldungen beim Konvertieren von Niedersachsen. Einen Debug-Log krieg ich auch nicht.

... hätt' ja sein können. So wissen wir jetzt zwar, dass es keine Debug-Meldung gab, aber ob die Insel kommentarlos verarbeit oder auch noch die Debug-Meldungen-ausgeben Routine kaputt ist, wissen wir nicht.

Gruss Christian

stimmt, daher warte ich ja auch auf Input von Klaus. Bestimmt benutzt er auch eigene Styles, oder wie immer sowas bei MapsForge heisst, und da könnte auch alles Mögliche herkommen.

Offline

#25 2014-09-25 19:36:19

wambacher
Member
From: Schlangenbad/Wambach, Germany
Registered: 2009-12-16
Posts: 16,755
Website

Re: Wer könnte einige Problem-Polygone prüfen?

couchmapper wrote:

Das Ticket hier riecht sehr nach eurem Problem: https://code.google.com/p/mapsforge/iss … ail?id=431

OK, I have analyzed the situation further and printed the offending polygon. It looks like you check if the geometry is an instance of a Polygon, but forgot that if there is only a single linear ring as the outer boundary this check fails.

Ja, das ist bei Juist genau der Fall. Naja, das Ticket ist ja erst von März 2013 sad

Last edited by wambacher (2014-09-25 19:37:27)

Offline

Board footer

Powered by FluxBB