Re: [Talk-de] Waterway Relation / Unterschiedliche Namen Unter/Oberlauf

2016-04-24 Diskussionsfäden Werner Hoch 
Am Donnerstag, den 14.04.2016, 15:49 +0200 schrieb Christoph Hormann:
> On Thursday 14 April 2016, Florian Lohoff wrote:
> > 
> > 
> > Ich halte hier die Relation eigentlich auch für Mißbräuchlich. Das
> > ist wieder nur eine Sammelrelation. Eigentlich müsste die
> > Fließgewässernummer einfach als ref auf alle Teilstücke und gut.
> > Das
> > wieder mit einer Sammelrelation zusammenzuführen - ist - ähm -
> > naja.
> Die Idee hinter den waterway-Relationen ist eigentlich Namen-
> basierend - 
> der Fluss mit dem Namen 'Elbe' existiert als Relation, obwohl er
> ggf. 
> aus vielen hundert einzelnen ways besteht.  Die Namen in x 
> verschiedenen Sprachen sowie wikidata-Tags etc. muss man dann nicht
> an den ganzen ways anbringen, sondern nur einmal und die 
> waterway-Relation 'Moldau' erhält als destination-Tag 'Elbe', so dass
> sogar die Struktur des Flussnetzwerkes abgebildet wird.

Das optionale destination tag wurde mit aufgenommen, um durch diese
kleine Redundaz zwischen dem destination tag und der Verbindung von
Wasserwegen durch Nodes und Ways, die Kontrolle zu vereinfachen.

Ein Fluss mit destination=Rhein sollte dann auch in den Rhein fließen
(durch verbundene Waterway ways).

> In der Praxis funktioniert das natürlich nicht, denn die Elbe heißt
> bei der Mündung der Moldau lokal 'Labe', so dass das Ganze in die
> Hose geht:
> 
> http://www.openstreetmap.org/relation/1730536
> http://www.openstreetmap.org/relation/123822
> 
> Und das ist nur ein ganz einfaches Beispiel, geht noch deutlich 
> komplizierter wie hier:
> 
> http://www.openstreetmap.org/relation/1067987
> 
> Das Problem ist dabei weniger der Charakter als Sammel-Relation,
> sondern dass das Konzept eines eindeutigen und überprüfbaren Namens
> in der Realität einfach nicht existiert.  Flüsse werden lokal benannt
> und die 
> Benennung der waterway-Relationen ist im Allgemeinen eine recht 
> willkürliche und subjektive Extrapolation.  Bei Wikipedia
> funktioniert 
> das, denn ein Wikipedia-Artikel kann ggf. unterschiedliche
> Sichtweisen darstellen oder im ungefähren bleiben, bei einer Geo-
> Datenbank muss jedoch eine eindeutige Geometrie vorhanden sein.

Viele Flüsse sind neben Wikipedia auch in Wikidata gelistet. Diese
Daten lassen sich (neben den reinen Verbindungsdaten) auswerten.
Wikidata hat in seinen Eigenschaften ebenfalls Eigenschaften, die die
Verbindung von Flüssen beschreibt. (mouth_of_watercourse, lake_outflow,
...)

http://www.h-renrew.de/h/osm/osmchecks/07_watershed/index.html

Hier die Daten der Schweiz:
http://www.h-renrew.de/h/osm/osmchecks/07_watershed/planet/wikidata_osm
_CH.html

MfG
Werner

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

Re: [Talk-de] Waterway Relation / Unterschiedliche Namen Unter/Oberlauf

2016-04-24 Diskussionsfäden Werner Hoch 
Hallo,

Am Donnerstag, den 14.04.2016, 11:56 +0200 schrieb Volker Schmidt:
> http://wiki.openstreetmap.org/wiki/Relation:waterway
> sagt:
> 
> *name*
> Name of the river  *... *When a river gets multiple names (f.e.
> because it
> passes in multiple language regions), use all different names in the
> name
> tag, ordered from source to mouth, and split by hyphens. The
> individual
> sections can still get their localised name for that section.

Leider wurde die Seite ohne Diskussion geändert. da ist auch diese
komische name-Definition gemacht worden:
http://wiki.openstreetmap.org/w/index.php?title=Relation%3Awaterway
e=revision=1114522=1103161

Eine Aufzählung im Namen mit Semicolon habe ich in der Praxis noch
nicht gesehen.

Die lokale Bezeichnung kommt immer an den Way und wird auch so
gerendert.
Die Relation ist für den gesamten Wasserlauf gedacht, da hier dann auch
die Verbindung zu Wikidata, wikipeda, ref, ... hergestellt wird.

MfG
Werner


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

Re: [Talk-de] Wahlbezirksgrenzen als boundary/administrative

2016-04-24 Diskussionsfäden Martin Koppenhoefer 


sent from a phone

Il giorno 24 apr 2016, alle ore 13:54, Harald Hartmann 
 ha scritto:

>> Ist es möglich sich eine eigene Datenbank auf Basis der OSM-API und
>> allem drumherum aufzusetzen, um die Daten pflegen und erfassen zu
>> können und gleichzeitig die Tools zu Nutzen, die wir um unsere
>> OSM-Datenbank herum gebaut haben, z.B. JOSM?
> 
> Kurz und bündig: Ja. So macht es z.B. die OpenHistoricalMap [1]
> 
> [1] https://wiki.openstreetmap.org/wiki/Open_Historical_Map


ich halte das für schwer möglich, klar, auf den ersten Blick sieht es so aus 
als könnte es funktionieren, aber so was wird recht schnell nicht mehr 
synchronisiert sein und kaum noch miteinander in Einklang zu bringen. D.h. wenn 
man eine Parallelwelt ohne jegliche Bezüge (ausser räumlichen) haben will geht 
das sicherlich, ansonsten aber nicht. Sieht man vielleicht auch schon bei der 
OHM: das Meer von heute passt nicht zu den historischen Daten. (AFAIK ist das 
Projekt OHM nicht besonders lebendig, das als gelungenen Fork hinzustellen ist 
schwierig).

Gruß,
Martin 


PS: dieses ganze Highway netz passt vom Datenmodell her irgendwie nicht zum 
Rest ;-)
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Wahlbezirksgrenzen als boundary/administrative

2016-04-24 Diskussionsfäden Harald Hartmann 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

> Ist es möglich sich eine eigene Datenbank auf Basis der OSM-API und
> allem drumherum aufzusetzen, um die Daten pflegen und erfassen zu
> können und gleichzeitig die Tools zu Nutzen, die wir um unsere
> OSM-Datenbank herum gebaut haben, z.B. JOSM?

Kurz und bündig: Ja. So macht es z.B. die OpenHistoricalMap [1]

[1] https://wiki.openstreetmap.org/wiki/Open_Historical_Map
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBAgAGBQJXHLPiAAoJEIuLcq40+VqtE7cIAOZ/0Tw8wxMx6XWee/7q24oR
Rwd0o96RfbHPg6UYJhQ2L0nuxBnnUIV3P6OlFyl9th+GJ3wYnQAQ/PBIQwAbB3Yt
noEjmp4NanZLXq/FB8Gf2jrkDjXCwGkJWQkMhD1nxjP9OCjwRySMoMtUxrwoc/yQ
4iQY9ikB9Twyj22PnBmWsCjaajMO145uwRI5TEgR1Aw/TeNkykUNLgx8/O3d7w3p
scxN6x0p5p67uqUADQK2wH+7nvAbG48Rb1NPQEyN7iQi+SO+DCLqiXCJAj0k/tIl
XMWSH+xjonAHVIhZ38EyioLNblfLLxO+uleS4nyiWzvfTDDjaId1PNQ9FPsm0/U=
=cEkh
-END PGP SIGNATURE-

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

Re: [Talk-de] Wahlbezirksgrenzen als boundary/administrative

2016-04-24 Diskussionsfäden Falk Zscheile 
Am 15. April 2016 um 00:32 schrieb Frederik Ramm :
> Hi,
>
> On 04/14/2016 12:51 PM, Florian Lohoff wrote:
>> Irgendwie finde ich das mit dem boundary=administrative ziemlich
>> unglücklich. Auf der einen Seite ist das natürlich richtig das das
>> "Administrative" Grenzen sind - aber ich vermute das OSMAnd
>> jetzt nicht der einzige ist der sich da verwirren lässt.
>
> Wenn's nach mir geht, raus mit dem Mist. Verwaltungsgrenzen und
> PLZ-Gebiete kann ich noch einsehen. Aber Wahlkreise,
> Grundschuleinzugsgebiete, Kirchengemeindegrenzen, das Sendegebiet vom
> NDR und das Liefergebiet vom Pizzadienst sind Grenzen, die in OSM nichts
> zu suchen haben.
>

Einmal angenommen bei OSM kommen wir zu dem Konsens, dass derlei Daten
nicht in die OSM-Datenbank sollen, es aber eine relevante Gruppe gibt,
die solche Daten erheben und pflegen möchte -- welche Alternativen
gäbe es? Ist es möglich sich eine eigene Datenbank auf Basis der
OSM-API und allem drumherum aufzusetzen, um die Daten pflegen und
erfassen zu können und gleichzeitig die Tools zu Nutzen, die wir um
unsere OSM-Datenbank herum gebaut haben, z.B. JOSM?

Gruß Falk

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