Re: [Talk-de] osmconvert und nested relations

[dktue]

Hallo,

ich hatte mit Markus, dem Entwickler von osmconvert Kontakt: Er hat den 
neuen Schalter "--complete-boundaries" eingebaut. Ich habe die Funktion 
bereits getestet, sie funktioniert einwandfrei und nimmt jetzt alle 
Grenzen vollständig in die Ausgabe auf! :-)


Gruß
dktue

Am 16.06.2017 um 14:47 schrieb dktue:

Hallo,

ich schätze, Deine Vermutung ist richtig.

Im Quelltext [1, Zeile 11264] wird nur explizit auf type=multipolygon 
geprüft.


Gruß
dktue

[1] https://gitlab.com/osm-c-tools/osmctools/blob/master/src/osmconvert.c

Am 16.06.2017 um 11:59 schrieb Walter Nordmann:

wohl nix :(

Ich habe den Bereich mal etwas vergrößert, sodass auch "richtige" 
Multipolygone - also mit type=multipolygon - in der BBOX vorhanden 
sind. Diese werden komplett zur Verfügung gestellt. type=boundary 
aber wohl nicht.


Ein Blick in die Sources dürfte da wohl Klarheit bringen.

Ich würde mit osmosis clippen, da dort von Relationen und nicht (nur) 
Multipolygonen (kleiner aber feiner Unterschied) geredet wird. Und 
dort hab ich noch nie solche Probleme gehabt.


Gruss
walter


Am 16.06.2017 um 11:22 schrieb dktue:


Was mache ich falsch?



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



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



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

Re: [Talk-de] osmconvert und nested relations

[Christoph Hormann]

On Saturday 17 June 2017, Jochen Topf wrote:
> [...] Wir sind meilenweit hinten dran mit
> der Entwicklung. Es gibt wahnsinnig viele Sachen, die theoretisch
> vielleicht möglich wären, die praktisch aber nicht funkionieren.
> Vielleicht gibts sogar Versuche hier oder dort, aber praktisch ist
> das, was wir von den OSM-Daten wirklich nutzen, ziemlich klein.

Das ist sicher richtig - wenngleich es auch beim Mappen ein enormes 
ungenutztes Potential gibt (das, was von dem existierenden Wissen der 
Mapper und den verfügbaren Informationen wirklich gemappt wird ist 
insgesamt ziemlich wenig - man denke nur an die USA).

Das sollte uns aber nicht zu dem Schluss bringen, mehr Arbeit von den 
Entwicklern auf die Mapper zu übertragen, denn das würde am Ende nur 
dazu führen, dass die Mapper zunehmend per Hand Karten malen, also für 
kaum mehr weiterentwickelte Kartenstile, Router etc. Informationen 
mundgerecht vorkauen.  Das ist aber enorm kontraproduktiv, weil es am 
Ende fast jede innovative Entwicklung im Keim erstickt, denn die Daten 
sind dann natürlich kaum mehr für irgendwas anderes geeignet, als für 
diese etablierten Systeme - quasi die Umkehrung von dem Wildwuchs.

> Damit OSM als System funktioniert, das sich fortentwickelt und
> praktische Lösungen liefert, braucht es beides. Die Mapper, die Daten
> sammeln und erfassen und die Nutzer, die aus den Daten etwas machen.
> Aus dieser Zusammenarbeit entsteht eine nützliche Datensammlung.
> Fehlt das eine oder das andere, dann geht es nicht voran.

Genau - und vor allem sollten beide Seiten ein gesundes Maß an 
Unabhängigkeit und selbstständigem Denken wahren - wenn ich zum 
Beispiel Tagging-proposals sehe, bei denen der wesentliche Inhalt ist 
das soll dann so-und-so gerendert werden, dann kräuseln sich bei mir 
die Zehnägel.

Als Mapper zu versuchen, durch detaillierte Antizipation der 
Datennutzung den Erfolg eines Mapping-Konzeptes zu garantieren ist 
Irrsinn.  Der Erfolg oder Misserfolg ergibt sich am Ende wie Du schon 
andeutest erst aus der tatsächlichen Wechselwirkung zwischen Mapping 
und Datennutzung.  Und um nochmal auf den Ausgangspunkt zurückzukommen, 
oft sind dabei die 90-Prozent-Lösungen erfolgreicher, was natürlich 
ärgerlich ist, wenn man irgendwie mit den restlichen 10 Prozent zu tun 
hat.

-- 
Christoph Hormann
http://www.imagico.de/

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

Re: [Talk-de] osmconvert und nested relations

[Jochen Topf]

On Fri, Jun 16, 2017 at 11:04:27AM +0200, Christoph Hormann wrote:
> On Friday 16 June 2017, Jochen Topf wrote:
> >
> > Es gibt da eine Tendenz immer komplexere Dinge zu mappen, ohne dass
> > irgendwer diese Daten auch sinnvoll nutzt. Auf der einen Seite ist es
> > ja gut, wenn wir mehr Details und mehr Zusammenhänge erfassen, weil
> > nur Daten, die da sind, auch genutzt werden können. Aber auf der
> > anderen Seite schreckt die Komplexität doch die Entwickler ab.
> 
> In diesem Fall gibt es ein recht klares (wenn auch nicht immer einfach 
> bestimmbares) Kriterium: Wenn es für den Entwickler einfacher ist sich 
> den Zusammenhang aus den übrigen Daten herzuleiten, sollte man 
> gewöhnlich auf die Erfassung verzichten.  In diesem Fall ist role 
> admin_centre von der Bedeutung äquivalent mit 
> capital=yes/capital= auf dem entsprechenden Element.  Und 
> da der Entwickler letzteres aufgrund der Unvollständigkeit der 
> admin_centre eh auswerten wollen wird ist das Ganze am Ende meist 
> ziemlich überflüssig.
> 
> Ansonsten ist das "denkt denn niemand an die armen Entwickler"-Argument 
> mit Vorsicht zu genießen, wenn die Bequemlichkeit der Entwickler über 
> die Bequemlichkeit der Mapper gestellt wird und dem Mapper sinnlose 
> Arbeiten aufgedrückt werden nur weil der Entwickler sich keine Arbeit 
> machen möchte oder seine Arbeit teurer ist als die des Mappers (was 
> insbesondere bei OSM ein sehr verbreitetes Problem ist).

Es wäre ja schön, wenn wir die Arbeit der Mapper und der Entwickler
irgendwie verrechnen könnten und schauen, was "unterm Strich" am
effizientesten ist oder so. Das könnte man machen, wenn OSM eine Firma
ist, die ihre Leute passend einteilen kann. Aber so ist das halt nicht.

Das Problem ist ein anderes: Der Mapper denkt, sein komplexes Mapping
würde auch magisch irgendwie verwendet. Es erscheint auf der Karte oder
ist findbar im Nominatim oder wird beim Routing verwendet. Das ist aber
häufig nicht der Fall. Wir sind meilenweit hinten dran mit der
Entwicklung. Es gibt wahnsinnig viele Sachen, die theoretisch vielleicht
möglich wären, die praktisch aber nicht funkionieren. Vielleicht gibts
sogar Versuche hier oder dort, aber praktisch ist das, was wir von den
OSM-Daten wirklich nutzen, ziemlich klein.

Dadurch fehlt hier aber ein ganz wichtiges Korrektiv: Klassisch ist das
so, dass der Mapper sich auf das stützen kann, was auf der Karte
erscheint. Mapper mappen solche Sachen konsistent und qualitativ
einigermaßen gut, wo sie das Ergebnis anschauen können. Ob das nun gut
ist oder nicht, Mapper orientieren sich an der Karte (und auch an der
Visualisierung der diversen Tools zur Qualitätssicherung). Aber da, wo
es diese "guidance" durch solche Karten und Tools nicht gibt, gibt es
einen unglaublichen Wildwuchs. Der Wildwuchs ist gut, wenn aktiv in dem
Bereich etwas voran geht. So kann man nämlich verschiedene Dinge
ausprobieren und dann das, was am besten funktioniert, systematischer
umsetzen. Dazu braucht es aber irgendwen, der die Daten auch nutzt und
sagt, was funktioniert und was nicht. Und das fehlt halt in vielen
Bereichen. Beim public transport z.B. ist diese "Diskussion" noch voll
im Gange, da bewegt sich was und neue Dinge werden probiert. Aber in
ganze vielen anderen Bereichen, gerade was komplexe Relationen angeht,
da passiert das nicht.

Damit OSM als System funktioniert, das sich fortentwickelt und
praktische Lösungen liefert, braucht es beides. Die Mapper, die Daten
sammeln und erfassen und die Nutzer, die aus den Daten etwas machen. Aus
dieser Zusammenarbeit entsteht eine nützliche Datensammlung. Fehlt das
eine oder das andere, dann geht es nicht voran.

Jochen
-- 
Jochen Topf  joc...@remote.org  https://www.jochentopf.com/  +49-351-31778688

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

Re: [Talk-de] osmconvert und nested relations

[Martin Koppenhoefer]

sent from a phone

On 16. Jun 2017, at 13:18, Christoph Hormann  wrote:

>> admin centre des Landes Berlin
>> (level 4) ist.
> 
> 
> Geodaten sind eine Abstraktion der Realität und es gibt fast immer, 
> insbesondere bei von Menschen geschaffenen Dingen wie 
> Verwaltungsstrukturen, Dinge, die das Datenmodell nicht abbilden kann.


was ich sage ist, dass die Rolle admin_centre in den Adminrelationen nicht 
dasselbe ist wie der capital key. Letzteres sagt lediglich etwas über die 
administrative Bedeutung, was aber für viele usecases völlig ausreichend ist.

Wenn wir Dinge mit dem etablierten Modell nicht abbilden können (was ich hier 
nicht sehe), dann sollten wir prüfen, ob und wie wir unser Modell ggf. 
erweitern können/wollen.
"Geht nicht" gibt's nicht ;-)

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

Re: [Talk-de] osmconvert und nested relations

[dktue]

Hallo,

ich schätze, Deine Vermutung ist richtig.

Im Quelltext [1, Zeile 11264] wird nur explizit auf type=multipolygon 
geprüft.


Gruß
dktue

[1] https://gitlab.com/osm-c-tools/osmctools/blob/master/src/osmconvert.c

Am 16.06.2017 um 11:59 schrieb Walter Nordmann:

wohl nix :(

Ich habe den Bereich mal etwas vergrößert, sodass auch "richtige" 
Multipolygone - also mit type=multipolygon - in der BBOX vorhanden 
sind. Diese werden komplett zur Verfügung gestellt. type=boundary aber 
wohl nicht.


Ein Blick in die Sources dürfte da wohl Klarheit bringen.

Ich würde mit osmosis clippen, da dort von Relationen und nicht (nur) 
Multipolygonen (kleiner aber feiner Unterschied) geredet wird. Und 
dort hab ich noch nie solche Probleme gehabt.


Gruss
walter


Am 16.06.2017 um 11:22 schrieb dktue:


Was mache ich falsch?



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



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

Re: [Talk-de] osmconvert und nested relations

[Jochen Topf]

On Fri, Jun 16, 2017 at 11:22:12AM +0200, dktue wrote:
> vielen Dank für den Hinweis bezüglich der Relationen: In der Tat handelt es
> sich beim der Grenze nicht um eine geschachtelte Relation sondern um eine
> einfache Relation mit ausschließlich Ways als Mitgliedern.
> 
> Ich habe folgenden Test gemacht: Ich habe die Daten der Regierungsbezirks
> Tübingens heruntergeladen [1] und mit osmconvert und folgendem Parameter
> geschnitten:
> 
> osmconvert.exe tuebingen-regbez-latest.osm.pbf
> -b=9.07966,48.50007,9.08387,48.50192 --complex-ways -o=test.osm
> 
> Ich hätte erwartet, dass in der Ausgabe-Datei die vollständigen Grenzen von
> Tübingen und Kusterdingen enthalten sind. Das ist aber leider nicht der
> Fall.

Ich weiss nicht genau, wie osmconvert das handhabt. Bei osmium kann man
einstellen, welche Relationen man vervollständigt haben möchte. Siehe
http://docs.osmcode.org/osmium/latest/osmium-extract.html .
Normalerweise werden nur multipolygon-Relationen vervollständigt, aber
man kann auch sagen, dass das auch für die Grenzen gelten soll.

Jochen
-- 
Jochen Topf  joc...@remote.org  https://www.jochentopf.com/  +49-351-31778688

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

Re: [Talk-de] osmconvert und nested relations

[Christoph Hormann]

On Friday 16 June 2017, Martin Koppenhoefer wrote:
> >
> >  In diesem Fall ist role
> > admin_centre von der Bedeutung äquivalent mit
> > capital=yes/capital= auf dem entsprechenden Element.
>
> ist sie m.E. nicht bzw. nur in bestimmten Fällen (wenn es nur ein
> admin Objekt gibt, für das der place ein admin_centre ist). Capital
> gibt die Bedeutung für die Administration wieder, z.B. ist Berlin
> capital=yes oder 2, während es auch admin centre des Landes Berlin
> (level 4) ist.

Geodaten sind eine Abstraktion der Realität und es gibt fast immer, 
insbesondere bei von Menschen geschaffenen Dingen wie 
Verwaltungsstrukturen, Dinge, die das Datenmodell nicht abbilden kann.  
Du sagst ja auch nicht, dass wir Multipolygone für administrative 
Grenzen abschaffen sollen nur weil es gelegentlich Sonderfälle gibt, 
die das nicht abdeckt.  

Im genannten Fall würden die meisten Entwickler sowieso eine Heuristik 
anlegen und - falls ein Objekt mit capital=4 nicht existiert - davon 
ausgehen, dass das nächst niedrigere capital=* diese Funktion erfüllt.

-- 
Christoph Hormann
http://www.imagico.de/

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

Re: [Talk-de] osmconvert und nested relations

[Martin Koppenhoefer]

sent from a phone

> On 16. Jun 2017, at 11:04, Christoph Hormann  wrote:
> 
>  In diesem Fall ist role 
> admin_centre von der Bedeutung äquivalent mit 
> capital=yes/capital= auf dem entsprechenden Element.


ist sie m.E. nicht bzw. nur in bestimmten Fällen (wenn es nur ein admin Objekt 
gibt, für das der place ein admin_centre ist). Capital gibt die Bedeutung für 
die Administration wieder, z.B. ist Berlin capital=yes oder 2, während es auch 
admin centre des Landes Berlin (level 4) ist.


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

Re: [Talk-de] osmconvert und nested relations

[Martin Koppenhoefer]

sent from a phone

> On 16. Jun 2017, at 10:28, Jochen Topf  wrote:
> 
> Die Frage wäre hier erstmal: Wer macht eigentlich was mit diesen Daten?


IMHO nicht, es geht darum, die Realität so gut es geht zu beschreiben und 
höchstens an zweiter Stelle darum, wer dann was mit diesen Daten macht. Es gibt 
ja bereits seit längerem Mapper, die places als areas mappen. Wenn man auf 
nodes als alleinig sinnvollem Weg Siedlungen zu mappen besteht, dann verhindert 
man "den Fortschritt". Wer das nicht auswerten will muss es ja nicht tun. Wir 
mappen nicht  (nur) für bestimmte Usecases (allein). 

Es stimmt allerdings, dass ein zentraler Node auch seinen Charme (lies: 
Informationsgehalt) hat, ich bin daher nicht für das Ersetzen sondern dafür, 
beides zu machen, insofern sollte man vielleicht place relationen machen, die 
den node explizit mit der area verbinden, und diese Relationen dann in die 
admin relationen als admin centre einbinden?

Was übrigens auch gelegentlich nicht passt: nur einen place als admin centre, 
teilweise gibt es da (in der Realität) auch eine Teilung auf mehrere Orte.

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

Re: [Talk-de] osmconvert und nested relations

[Walter Nordmann]

wohl nix :(

Ich habe den Bereich mal etwas vergrößert, sodass auch "richtige" 
Multipolygone - also mit type=multipolygon - in der BBOX vorhanden sind. 
Diese werden komplett zur Verfügung gestellt. type=boundary aber wohl nicht.


Ein Blick in die Sources dürfte da wohl Klarheit bringen.

Ich würde mit osmosis clippen, da dort von Relationen und nicht (nur) 
Multipolygonen (kleiner aber feiner Unterschied) geredet wird. Und dort 
hab ich noch nie solche Probleme gehabt.


Gruss
walter


Am 16.06.2017 um 11:22 schrieb dktue:


Was mache ich falsch?



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

Re: [Talk-de] osmconvert und nested relations

[dktue]

Hallo,

vielen Dank für den Hinweis bezüglich der Relationen: In der Tat handelt 
es sich beim der Grenze nicht um eine geschachtelte Relation sondern um 
eine einfache Relation mit ausschließlich Ways als Mitgliedern.


Ich habe folgenden Test gemacht: Ich habe die Daten der 
Regierungsbezirks Tübingens heruntergeladen [1] und mit osmconvert und 
folgendem Parameter geschnitten:


osmconvert.exe tuebingen-regbez-latest.osm.pbf 
-b=9.07966,48.50007,9.08387,48.50192 --complex-ways -o=test.osm


Ich hätte erwartet, dass in der Ausgabe-Datei die vollständigen Grenzen 
von Tübingen und Kusterdingen enthalten sind. Das ist aber leider nicht 
der Fall.


Was mache ich falsch?

Viele Grüße
dktue

Am 14.06.2017 um 19:07 schrieb Michael Reichert:

Hallo,

Am Mittwoch, den 14.06.2017, 15:29 +0200 schrieb dktue:

ich schneide derzeit OSM-Daten mit osmconvert und dem schalter
--complex-ways um Relationen zu vervollständigen.

Auf den ersten Blick scheint es, als könnte osmconvert allerdings
nur
einfache Relationen vervollständigen, nicht aber Relationen die
wiederum
Relationen als Elemente haben (typisch für Grenzen).

Grenzenrelationen referenzieren keine anderen Relationen. Die einzigen
anerkannten Mitglieder sind
- Ways mit der Rolle outer
- Ways mit der Rolle inner
- Ways ohne Rolle (der Auswerter darf dann raten)
- 1 Node mit der Rolle admin_centre
- 1 Node mit der Rolle label


Kann mir jemand sagen, ob ich richtig liege? Falls ja, ob ich das
mit
osmconvert hinbekomme? Falls nein, mit welchem Werkzeug ist das
bewerkstelligen kann?

Laut Doku dürfte die Strategie "smart" des osmium-tool das
unterstützten.
http://docs.osmcode.org/osmium/latest/osmium-extract.html
http://osmcode.org/osmium-tool/manual.html#creating-geographic-extracts

Viele Grüße

Michael

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



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

Re: [Talk-de] osmconvert und nested relations

[Christoph Hormann]

On Friday 16 June 2017, Jochen Topf wrote:
>
> Es gibt da eine Tendenz immer komplexere Dinge zu mappen, ohne dass
> irgendwer diese Daten auch sinnvoll nutzt. Auf der einen Seite ist es
> ja gut, wenn wir mehr Details und mehr Zusammenhänge erfassen, weil
> nur Daten, die da sind, auch genutzt werden können. Aber auf der
> anderen Seite schreckt die Komplexität doch die Entwickler ab.

In diesem Fall gibt es ein recht klares (wenn auch nicht immer einfach 
bestimmbares) Kriterium: Wenn es für den Entwickler einfacher ist sich 
den Zusammenhang aus den übrigen Daten herzuleiten, sollte man 
gewöhnlich auf die Erfassung verzichten.  In diesem Fall ist role 
admin_centre von der Bedeutung äquivalent mit 
capital=yes/capital= auf dem entsprechenden Element.  Und 
da der Entwickler letzteres aufgrund der Unvollständigkeit der 
admin_centre eh auswerten wollen wird ist das Ganze am Ende meist 
ziemlich überflüssig.

Ansonsten ist das "denkt denn niemand an die armen Entwickler"-Argument 
mit Vorsicht zu genießen, wenn die Bequemlichkeit der Entwickler über 
die Bequemlichkeit der Mapper gestellt wird und dem Mapper sinnlose 
Arbeiten aufgedrückt werden nur weil der Entwickler sich keine Arbeit 
machen möchte oder seine Arbeit teurer ist als die des Mappers (was 
insbesondere bei OSM ein sehr verbreitetes Problem ist).

-- 
Christoph Hormann
http://www.imagico.de/

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

Re: [Talk-de] osmconvert und nested relations

[Jochen Topf]

On Fri, Jun 16, 2017 at 10:02:58AM +0200, Martin Koppenhoefer wrote:
> > On 14. Jun 2017, at 19:07, Michael Reichert  wrote:
> > 
> > Grenzenrelationen referenzieren keine anderen Relationen. Die einzigen
> > anerkannten Mitglieder sind
> > - Ways mit der Rolle outer
> > - Ways mit der Rolle inner
> > - Ways ohne Rolle (der Auswerter darf dann raten)
> > - 1 Node mit der Rolle admin_centre
> > - 1 Node mit der Rolle label
> 
> 
> 
> gibt es einen Grund, als admin_centre nur nodes zuzulassen? Wieso keine place 
> polygone?

Die Frage wäre hier erstmal: Wer macht eigentlich was mit diesen Daten?

Es gibt da eine Tendenz immer komplexere Dinge zu mappen, ohne dass
irgendwer diese Daten auch sinnvoll nutzt. Auf der einen Seite ist es ja
gut, wenn wir mehr Details und mehr Zusammenhänge erfassen, weil nur
Daten, die da sind, auch genutzt werden können. Aber auf der anderen
Seite schreckt die Komplexität doch die Entwickler ab. Nun macht es das
Leben eines Entwicklers nicht wirklich schwieriger, ob es 10
verschiedene Typen von Shops gibt oder 100 oder 1000. Aber komplexe
Relationen auswerten, das ist schwierig und kann selbst bei kleinen
Änderungen erhebliche Auswirkungen haben. Da muss man schon viel genauer
hinsehen, was sinnvoll ist und was nicht.

Jochen
-- 
Jochen Topf  joc...@remote.org  https://www.jochentopf.com/  +49-351-31778688

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

Re: [Talk-de] osmconvert und nested relations

[Martin Koppenhoefer]

sent from a phone

> On 14. Jun 2017, at 19:07, Michael Reichert  wrote:
> 
> Grenzenrelationen referenzieren keine anderen Relationen. Die einzigen
> anerkannten Mitglieder sind
> - Ways mit der Rolle outer
> - Ways mit der Rolle inner
> - Ways ohne Rolle (der Auswerter darf dann raten)
> - 1 Node mit der Rolle admin_centre
> - 1 Node mit der Rolle label



gibt es einen Grund, als admin_centre nur nodes zuzulassen? Wieso keine place 
polygone?


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

Re: [Talk-de] osmconvert und nested relations

[Michael Reichert]

Hallo,

Am Mittwoch, den 14.06.2017, 15:29 +0200 schrieb dktue:
> ich schneide derzeit OSM-Daten mit osmconvert und dem schalter 
> --complex-ways um Relationen zu vervollständigen.
> 
> Auf den ersten Blick scheint es, als könnte osmconvert allerdings
> nur 
> einfache Relationen vervollständigen, nicht aber Relationen die
> wiederum 
> Relationen als Elemente haben (typisch für Grenzen).

Grenzenrelationen referenzieren keine anderen Relationen. Die einzigen
anerkannten Mitglieder sind
- Ways mit der Rolle outer
- Ways mit der Rolle inner
- Ways ohne Rolle (der Auswerter darf dann raten)
- 1 Node mit der Rolle admin_centre
- 1 Node mit der Rolle label

> Kann mir jemand sagen, ob ich richtig liege? Falls ja, ob ich das
> mit 
> osmconvert hinbekomme? Falls nein, mit welchem Werkzeug ist das 
> bewerkstelligen kann?

Laut Doku dürfte die Strategie "smart" des osmium-tool das
unterstützten.
http://docs.osmcode.org/osmium/latest/osmium-extract.html
http://osmcode.org/osmium-tool/manual.html#creating-geographic-extracts

Viele Grüße

Michael

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

[Talk-de] osmconvert und nested relations

[dktue]

Hallo,

ich schneide derzeit OSM-Daten mit osmconvert und dem schalter 
--complex-ways um Relationen zu vervollständigen.


Auf den ersten Blick scheint es, als könnte osmconvert allerdings nur 
einfache Relationen vervollständigen, nicht aber Relationen die wiederum 
Relationen als Elemente haben (typisch für Grenzen).


Kann mir jemand sagen, ob ich richtig liege? Falls ja, ob ich das mit 
osmconvert hinbekomme? Falls nein, mit welchem Werkzeug ist das 
bewerkstelligen kann?


Vielen Dank im Voraus!

Gruß
dktue

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