date:20120710

On Tue, Jul 10, 2012 at 12:10:42AM -0700, Paul Norman wrote:
 I know that there was some discussion as to if it would be necessary to
 refrain from conducting any imports while the redaction is in progress.
 Imports are not likely to conflict with the redaction bot but may cause load
 issues on the API. If it is (or becomes) necessary to restrict imports while
 it is running, can we get an official announcement to the blog (or
 announce@)

Whether it is necessary or not doesn't really matter. It is just common sense
not to do two large-scale things at once. If there are any problems, it becomes
harder to sort out whats what. So don't do anything large-scale while the
redaction process runs.

Jochen
-- 
Jochen Topf  joc...@remote.org  http://www.remote.org/jochen/  +49-721-388298


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

[OSM-talk] OSM2Tab: How to Compile C# / Experience

2012-07-10 Diskussionsfäden Alexander / AddisMap

Hi!

we are trying to use http://code.google.com/p/osm2tab/

Does anybody have experience with this project and knows if it is stable?

Can anybody assist with compiling the project?

We already contacted the author but did not get a response so far.

Best Regards,
  Alexander


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

[OSM-talk] IndoorAtlas

2012-07-10 Diskussionsfäden sabas88

Hello,
I've just read this[0] article on The Verge, about a startup working on
indoor navigation.
Do you think it could work with OSM? After I read it came to my mind the
IndoorOSM proposal [1]..
And in the video they seem to use GMaps to georeference the floor plans!

Regards,
Stefano

[0]
http://www.theverge.com/2012/7/10/3148926/indooratlas-indoor-navigation-magnetic-field
[1] http://wiki.openstreetmap.org/wiki/IndoorOSM
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Submitting POI to OSM made easy

2012-07-10 Diskussionsfäden moenk

Dear all,

I'd like to introduce a tiny tool. It's purpose is to submit POI to the OSM
database. The focus is not to replace things like Potlatch or JOSM, it was
developed for Geocachers for easy POI submitting. But I'm sure you'll know
some people who might have use for this simple mapping tool.

Just point on a map and enter some information what can be found there. Also
it is possible to upload geotagged JPGs or GPX from navigation devices. It's
so easy that I assume even my grandma could do it. The most complicated
thing is getting the required account for OSM.

Let me know what you think about it: http://yapis.eu/?id=0lang=en

Cheers,

-moenk


-

--
View this message in context: 
http://gis.19327.n5.nabble.com/Submitting-POI-to-OSM-made-easy-tp5715878.html
Sent from the General Discussion mailing list archive at Nabble.com.

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

Re: [OSM-talk] Licence redaction ready to begin

2012-07-10 Diskussionsfäden Michael Collinson


On 09/07/2012 23:00, Andrew Guertin wrote:

On 07/09/2012 04:46 PM, Richard Fairhurst wrote:
   

Where data has been redacted, any attempt to access it from the API
or the site's 'browse' pages will return a response to that effect.
 

What methods will still exist to get redacted data?

* Old planet files (or other old copies of data)
* Full history file?
* Anything else?

Just curious,
--Andrew
   


Old planet files and history files will continue to be available, and 
will licensed and can be used as CC-BY-SA data only.


Since it is CC-BY-SA must not be re-introduced into the live database!

Mike

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

[OSM-talk] Can Mapzen POI collected get some love?

2012-07-10 Diskussionsfäden John Harvey


Hey!

I keep hoping that Mapzen POI Collector will magically return to 
working, but every time I try I'm sadly disappointed.  As far as I can 
tell, it is still the best OSM editor for the iPhone - if anyone can 
recommend a better replacement, I'd love to hear it.  From what I 
understand, Mapzen POI Collector is basically no longer supported by the 
Cloudmade guys and a change to how it authorizes against the OSM servers 
has broken it:


http://help.openstreetmap.org/questions/9412/mapzen-unable-to-log-in

Any chance someone more technically savvy than me can give this problem 
some love?  I'd really like to get back to adding content using my iPhone.


Thanks!

John



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

Re: [OSM-talk-nl] Fwd: [OSM-talk] Licence redaction ready to begin

2012-07-10 Diskussionsfäden Stefan de Konink

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 09-07-12 23:29, Henk Hoff wrote:
 Ter info.

Naar aanleiding van deze e-mail vraag ik mij af waarom het proces nu
pas in gang gezet wordt, terwijl er nu maanden over de deadline is
heen gegaan.

Het is natuurlijk goed dat een recente CC-BY-SA set (eindelijk) is
gepubliceerd. Misschien een erg belangrijke vraag: is het proces van
de bot door gebruikers te volgen? Wat is de gebruikersnaam van de bot?
En hoe opereert de bot, maakt deze gebruik van de API?


Stefan
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEAREKAAYFAk/8LPUACgkQYH1+F2Rqwn1x1ACfU//th8TtQ2Dq1skIP0sEuv0J
RWUAoINaK7SSQLJgN0/YG340ZbKNcpGV
=q14q
-END PGP SIGNATURE-

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

Re: [OSM-talk-nl] Fwd: [OSM-talk] Licence redaction ready to begin

2012-07-10 Diskussionsfäden Sebastiaan Couwenberg

 Naar aanleiding van deze e-mail vraag ik mij af waarom het proces nu
 pas in gang gezet wordt, terwijl er nu maanden over de deadline is
 heen gegaan.

Dat vroeg ik mij ook af, en vond het volgende in het archief van de
Rebuild lijst:

The work with the license change bot have almost halted the last month,
with only around 10 commits and no real progress on the main algorithms.
This is partly because people have been occupied with other stuff (work,
life, mapping, final exams, etc) and partly because the problems with the
algorithms are really hard.

http://lists.openstreetmap.org/pipermail/rebuild/2012-June/000244.html

I am finally done with my final exams for this semester and have turned
my attention to the redaction bot. You have asked for updates and now I
finally have some.

http://lists.openstreetmap.org/pipermail/rebuild/2012-June/000252.html

 Het is natuurlijk goed dat een recente CC-BY-SA set (eindelijk) is
 gepubliceerd. Misschien een erg belangrijke vraag: is het proces van
 de bot door gebruikers te volgen? Wat is de gebruikersnaam van de bot?
 En hoe opereert de bot, maakt deze gebruik van de API?

Wat ik uit de Rebuild lijst opmaak is er nog geen definitieve
gebruikersnaam voor de bot gekozen, op dev gebruikt het momenteel de
username 'nobody'. Zie hiervoor de berichten van de Andy Allen in de draad
die begint bij:

http://lists.openstreetmap.org/pipermail/rebuild/2012-July/000295.html

In die draad is een link gepost naar de GitHub repo waar de bot code leeft:

https://github.com/gravitystorm/openstreetmap-license-change/

Het maakt gebruik van de redaction features in de API die voorheen nog
niet gebruikt werden.

Dit is wat ik tot dusver over de status van de license change heb kunnen
vinden. Ik vermoed dat in IRC logs nog wat details te vinden zijn die de
maillinglist nog niet bereikt hebben.

Mvg,

Bas


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

Re: [OSM-talk-nl] Fwd: [OSM-talk] Licence redaction ready to begin

2012-07-10 Diskussionsfäden Lambertus


On 10-7-2012 15:24, Stefan de Konink wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 09-07-12 23:29, Henk Hoff wrote:

Ter info.


Naar aanleiding van deze e-mail vraag ik mij af waarom het proces nu
pas in gang gezet wordt, terwijl er nu maanden over de deadline is
heen gegaan.


Op het blog van de OSM Foundation is verschenen op:
5 April:
http://blog.osmfoundation.org/2012/04/05/license-change-update-getting-it-right/

26 April:
http://blog.osmfoundation.org/2012/04/26/license-change-still-ongoing/


Het is natuurlijk goed dat een recente CC-BY-SA set (eindelijk) is
gepubliceerd.


Op 8 Mei en 13 Juni zijn nog full CC-BY-SA planets gepubliceerd en 
uiteraard werden alle changes volcontinue per minuut, uur en dag 
gepubliceerd onder CC-BY-SA via de 'redaction-period' directory op 
planet.openstreetmap.org


Misschien een erg belangrijke vraag: is het proces van

de bot door gebruikers te volgen? Wat is de gebruikersnaam van de bot?
En hoe opereert de bot, maakt deze gebruik van de API?



Kan er helaas weinig documentatie over vinden.

Misschien dat deze link je verder helpt?
http://lists.openstreetmap.org/pipermail/rebuild/2012-July/000297.html

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

Re: [OSM-talk-nl] [OSM-talk] Licence redaction ready to begin

2012-07-10 Diskussionsfäden Henk Hoff


Op 10 jul. 2012, om 16:27 heeft Lambertus het volgende geschreven:

 On 10-7-2012 15:24, Stefan de Konink wrote:
  [knip]
 Misschien een erg belangrijke vraag: is het proces van
 de bot door gebruikers te volgen? Wat is de gebruikersnaam van de bot?
 En hoe opereert de bot, maakt deze gebruik van de API?
 
 
 Kan er helaas weinig documentatie over vinden.
 
 Misschien dat deze link je verder helpt?
 http://lists.openstreetmap.org/pipermail/rebuild/2012-July/000297.html

Voor zover mijn informatie reikt: de bot gaat onder een speciale gebruikersnaam 
opereren.
Er zal gedurende het proces updates gegeven worden over de voortgang. 
Je zult kunnen zien dat er iets gewijzigd is, niet wat. Dit heeft te maken met 
licentie-issues.

Ja, de bot gaat gebruik maken van de API.

Gr,
Henk Hoff

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

Re: [OSM-talk-nl] [OSM-talk] Licence redaction ready to begin

2012-07-10 Diskussionsfäden Robert Elsenaar

Betekend dat dat ik mij na het passeren van de Bot niet speciaal kan richten op 
het hermappen van verloren gegane mapgedeelten?

Groet
Robert

From: Henk Hoff 
Sent: Tuesday, July 10, 2012 5:48 PM
To: OpenStreetMap NL discussion list 
Subject: Re: [OSM-talk-nl] [OSM-talk] Licence redaction ready to begin

Op 10 jul. 2012, om 16:27 heeft Lambertus het volgende geschreven:

  On 10-7-2012 15:24, Stefan de Konink wrote:
  [knip]
  Misschien een erg belangrijke vraag: is het proces van

de bot door gebruikers te volgen? Wat is de gebruikersnaam van de bot?

En hoe opereert de bot, maakt deze gebruik van de API?

  Kan er helaas weinig documentatie over vinden.

  Misschien dat deze link je verder helpt?
  http://lists.openstreetmap.org/pipermail/rebuild/2012-July/000297.html

Voor zover mijn informatie reikt: de bot gaat onder een speciale gebruikersnaam 
opereren.
Er zal gedurende het proces updates gegeven worden over de voortgang. 
Je zult kunnen zien dat er iets gewijzigd is, niet wat. Dit heeft te maken met 
licentie-issues.

Ja, de bot gaat gebruik maken van de API.

Gr,
Henk Hoff

---
Tekst ingevoegd door Panda GP 2012:

Als het hier gaat om een ongevraagde e-mail (SPAM), klik dan op de volgende 
link om de e-mail te herclasseren: It is SPAM!
---

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

[OSM-talk-ie] Licence Change - it's happening

2012-07-10 Diskussionsfäden Dermot McNally

Dear Irish community,

Most of you know in one form or another about the licence change. Many
of you also know that the data redaction was to take place in April.
It has of course taken quite a bit longer, but a lot of care has been
taken and we now have a good toolset that has been tested against a
real data set on a test API server. That test data set was Ireland, as
it happens.

Since the test ran satisfactorily, it is now planned to start the real
redaction - that is, to begin the process of identifying
non-ODbL-compatible data and:

a) Removing it from the data set. In Ireland, this will not entail the
loss of very much data

b) Making any non-compliant data from old versions unobtainable

This real redaction will start with Ireland and may commence as soon
as tomorrow. So if you see some unusual map changes, this may be the
cause.

Any discussion welcomed here or on IRC.

Thanks,
Dermot

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

[Talk-br] Reportagem de TV em Campo Grande

2012-07-10 Diskussionsfäden vitor

Oi pessoal,

Saiu uma reportagem da TV Record do Mato Grosso do Sul falando como o
Murilo Delmondes colocou bairros no mapa em Campo Grande:

https://www.youtube.com/watch?v=uAaCJBSqPto

Não sei se ele está na lista, mas parabéns, ficou excelente!


Vitor George
mapaslivres.org
twitter.com/mapaslivres
___
Talk-br mailing list
Talk-br@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Reportagem de TV em Campo Grande

2012-07-10 Diskussionsfäden Arlindo Pereira

Também gostei. Infelizmente não mencionaram o projeto nominalmente,
mas entendo os motivos pelos quais isso acontece. Achei bem didático.

[]s

2012/7/10 vitor vitor.geo...@gmail.com:
 Oi pessoal,

 Saiu uma reportagem da TV Record do Mato Grosso do Sul falando como o Murilo
 Delmondes colocou bairros no mapa em Campo Grande:

 https://www.youtube.com/watch?v=uAaCJBSqPto

 Não sei se ele está na lista, mas parabéns, ficou excelente!


 Vitor George
 mapaslivres.org
 twitter.com/mapaslivres



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


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

Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??

On Mon, Jul 09, 2012 at 11:51:13PM +0200, Christian Müller wrote:
 Am 09.07.2012 21:47, schrieb Frederik Ramm:
  Ist halt die Frage, fuer wen. Fuer den Router und den Renderer eben
  nicht.
 
 Genau das ist der Punkt.  Schmeißen wir die Relationen weg, verprellen
 wir Anwender und Entwickler bestimmter Anwendungsfälle genau so, wie es
 Unkenrufe geben wird, wenn plötzlich Namen einer Straße aus mehreren
 Elementen nur noch in der Relation auftauchen.

Keiner hat je davon geredet, Relationen wegzuschmeissen. Es ging in dieser
Diskussion darum, dass es schwierig ist, mit Relationen zu arbeiten. Die
Konsequenz davon kann natürlich nicht sein, dass man sie einfach abschafft.
Die Konsequenz ist, dass man sie durch etwas besseres ersetzt. Oder,
realistischer, dass man den one-size-fits-all-Ansatz ergänzt durch
Speziallösungen für Spezialfälle, mit denen dann jeweils einfacher zu
arbeiten ist.

Relationen haben uns neue und tolle Möglichkeiten gebracht. Die wollen wir
nicht missen. Aber sie haben uns eben auch eine Menge Schwierigkeiten gebracht.
Alle Leute, die ich kenne, die selbst Code schreiben, um Relationen
auszuwerten, haben Schwierigkeiten damit. Und die Mapper haben auch ihre
Schwierigkeiten damit. Ein kaputter Way hat Auswirkungen nur in der direkten
Nachbarschaft dieses Ways. Eine kaputte Relation kann Auswirkungen auf die
halbe Welt haben.

Das sind einfach Probleme, denen wir uns stellen müssen. Wir müssen überlegen,
wie wir konkret Fortschritte erzielen. Das geht am besten, in dem wir uns die
Erfahrungen mit OSM anschauen und davon lernen. Wir müssen drüber nachdenken,
wie man die OSM-Daten strukturieren so kann, dass sie leichter zu benutzen
und auszuwerten sind, ohne die Mächtigkeit des bestehenden Modells 
einzuschränken.
Und dazu muss man halt erstmal rausarbeiten, wo die Probleme sind. 

Jochen
-- 
Jochen Topf  joc...@remote.org  http://www.remote.org/jochen/  +49-721-388298


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

Re: [Talk-de] ergänzende Frage - bevor diese vergessen wird...

On Mon, Jul 09, 2012 at 11:59:54PM +0200, Jo wrote:
 komische Frage. Nah ja, ist schon entscheiden dass in Deutschland
 Relationen ersetzt werden? Ich habe nicht die ganze Diskussion gefolgt.
 Macht ihr wirklich einen Schritt rückwerts? Nur in Deutschland, oder alle
 deutschsprachige Gebiete? Oder sogar weltweit?
 
 Jedenfalls ist so ein Program relativ einfach zu schreiben. Was natürlich
 die Idee das Relationen schwierig auszuwerten sind, löscht..

Quark. Wenn Du schon nicht bereit bist, der Diskussion zu folgen, dann solltest
Du vielleicht auch nicht Deinen Senf dazu geben.

Es ist eben enorm schwierig so ein Programm zu schreiben. Weil es eben lauter
verschiedene Relationen gibt und verschiedene Interpretationen, welche Tags
genau wo hingehören usw. Darüber ging ja nun die ganze Diskussion hier. So
ein Programm kann man allenfalls für genau spezifizierte Einzelfälle schreiben
und daher gibts sowas in der Allgemeinheit, die Jan will, auch nicht.

Jochen
-- 
Jochen Topf  joc...@remote.org  http://www.remote.org/jochen/  +49-721-388298


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

Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??

2012-07-10 Diskussionsfäden Sarah Hoffmann

On Mon, Jul 09, 2012 at 11:51:13PM +0200, Christian Müller wrote:
 Am 09.07.2012 21:47, schrieb Frederik Ramm:
  Ist halt die Frage, fuer wen. Fuer den Router und den Renderer eben
  nicht.
 
 Genau das ist der Punkt.  Schmeißen wir die Relationen weg, verprellen
 wir Anwender und Entwickler bestimmter Anwendungsfälle genau so, wie es
 Unkenrufe geben wird, wenn plötzlich Namen einer Straße aus mehreren
 Elementen nur noch in der Relation auftauchen.

Kannst du konkrete Beispiele nennen von Anwendern, die irgendeiner Relation
ausser den drei wirklich gebrauchten (Routen, Abbiegerelation,
Multipolygon) nachweinen würden?

Wie Jochen bereits gesagt hat, muss man für die meisten Sachen den
Fall ohne Relationen ohnehin implementieren, weil es dieser Fall
immernoch der häufiger gebrauchte ist.

 Mich hat bisher kein einziges Argument gegen Relationen überzeugt. 
 Einzig evtl., dass sie schlecht gepflegt sind - das gilt aber auch für
 den restlichen OSM-Datenbestand.  Ich sehe z.B. immer wieder nicht
 verbundene Nodes, versehentlich verschobene, etc.

Relationen sind wesentlich leichter versehnlich kaputt zu machen als
Nodes, Wege und Tags, weil sie unsichtbar im Hintergrund herumlungern
und man nicht sofort sieht, dass man da etwas ändert. 

 Ich kann auch Sarah's Argumenten nicht folgen, dass OSM eine rein
 spatiale DB ist.  Es ist ein Mix - whatever works entscheidet, wer wie
 etwas modelliert.  Natürlich bedeuten diese Freiheiten Komplexität in
 der Auswertung - das ist aber imho dennoch weniger Aufwand, als alle zu
 zwingen, einheitlich zu mappen.  Ein Einwirken auf jeden der dann nach
 Überlegung falsch mappt, wird denjenigen die Lust am Mappen verderben.

Wenn du dir zuviel dieser Freiheiten herausnimmst, schränkst du
gewaltig die Freiheiten der anderen Mapper ein. Siehe oben. Relationen
sind in erster Linie ein Hindernis für deine Mitmapper. Es geht nicht
darum, 'einheitlich' zu mappen, es geht darum, das ganze so einfach wie
möglich zu halten, damit es für alle verständlich bleibt.

Ausserdem sind Relationen ein Motivationskiller, wenn es darum geht 
Fehler zu korrigieren. Wer mag schon einen Weg anfassen, der Mitglied 
in 15 Relationen ist. Ein Weg mit 15 kryptischen Tags ist zwar auch 
ein bisschen lästig, aber normalerweise kann man die Tags einfach 
ignorieren, frei nach dem Motto 'leben und leben lassen'.

 Für mich bedeuten Relationen Flexibilität - u.U. oft auch, dass ein und
 der gleiche geografische Sachverhalt eben vielfältig modelliert werden
 kann.  Warum begreifen wir das nicht weiterhin als Chance?  Warum wird
 stattdessen der Perfektionismus in primitiveren, unstrukturierten Daten
 gesucht, wie es Knoten und Weg nunmal sind?

Geografische Sachverhalte sollte man über Geometrie ausdrücken und
nicht durch irgendwelche künstlichen Strukturen. Natürlich könnten
wir für jede Bushaltestelle eine Relation erstellen, die besagt, ob
sie jetzt rechts von der Strasse liegt oder links. Aber was ist der
Sinn? Diese Information ist bereits in der DB, das heisst die Relation
bringt absolut nichts.

 Relationen sind auch dort, wo eigentlich alles auf dem Weg getaggt
 werden könnte, eine sinnvolle Ergänzung, z.B. um die Übersichtlichkeit
 zu bewahren und die Pflege zu vereinfachen.  Sie können evtl. 50+
 Übersetzungen halten, während die bsp.-haften, sechs zugehörigen Wege
 nur den regional üblichen Namen halten.  Auch mit Lookup-Tables/LUT
 versagt irgendwann der minimalistische Ansatz.  Je nachdem, wieviel
 Information über eine Menge von Wegen oder Knoten gehalten werden soll. 
 Auch wenn LUT evtl. in einigen Software-Projekten anzutreffen sind und
 dort eine Tag-Redundanz erfolgreich wegoptimieren, sind sie kaum
 dokumentiert und die Art ihrer Implementierung variiert.  Die Live-DB,
 die Live-Toolchain verwendet sie nicht.  Zudem wird mit der Auslagerung
 von Tags in LUT auch nichts anderes als eine Relation geschaffen, halt
 nur nicht vom Menschen.

Jetzt wirfst du irgendwelche technischen Begriffe in den Raum ohne
dir wirklich mal einen Kopf gemacht zu haben, wie das ganze eigentlich
funktioniert. Redundanz in den Tags ist bisher einfach kein grosses Problem 
gewesen. Die Art und Weise wie Datenbanken das handhaben, ist effizient 
genug. Wir haben ganz andere Ecken, wo wir ernsthafte Probleme mit der
Effizienz bekommen. In erster Linie bei der Berechnung der Weggeometrien
und dem Node-Lookup. 

 Da die Daten, wie die Softwareprojekte drumrum vermutlich nie perfekt
 sind, ist das mehr an Information und evtl. auch Redundanz eine Chance,
 gute QM-Tools zu bauen.  Am Beispiel der Bundesstraßen z.B. könnte man
 die Argumente derjenigen aufgreifen, die meinen
 
 man könne den Verlauf der Bundesstraße auch programmatisch anhand
 des ref= zusammenbauen und braucht die Relation gar nicht
 
 und gegen das prüfen, was manuell gepflegt wird.  In der Summe ergibt
 das eine gewisse Robustness gegen die Fehler, die man beim Mappen machen
 kann:
 
 - versehentlich Relation beschädigen
 - versehentlich

Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??

Obwohl ich sicher eine PostGIS DB installieren kann auf Linux oder Windows,
ist das fuer mich viel Aufwand, nur zum bestimmen ob etwas in etwas anderes
liegt. Auf Android gelingt das schon nicht mehr. Da bin ich dann froh wenn
ich sowas nur abfragen kann mittels eine Relation.

Auch um Daten, die hierarchisch eingetragen sind (ich denke jetzt an
Collections von Netzwerke von Routes), herunterzuladen mit der Overpass API
sind Relationen unschatzbar wertvoll.

Polyglot

2012/7/9 Sarah Hoffmann lon...@denofr.de

 On Mon, Jul 09, 2012 at 01:20:51PM +0200, Frederik Ramm wrote:
  Bei Relationen ist wenigstens ein generischer Support moeglich -
  gaengie Editoren koennen Dir wenigstens sagen, dass da eine Relation
  ist, selbst wenn sie nicht wissen, was sie bedeutet. Aber wenn im
  XML halt ploetzlich ein area oder route oder turnrestriction
  auftaucht, fliegt Dir der XML-Parser entweder um die Ohren oder
  schmeisst das Ding ganz weg.
 
  Eventuell sollte man alle diese neuen Datentypen dann in irgendwas
  gleichartiges kapseln, so dass eine Software, die den Datentyp nicht
  versteht, nicht total aufgeschmissen ist *duck*

 Genau aus diesem Grund finde ich Relationen so wie sie sind eigentlich
 eine geniale Idee, einfach und flexibel. (Aauch in der Verarbeitung,
 wenn man sich mal eine Minute von osm2pgsql lösen kann.)

 Wir haben mit Relationen keine technisches Problem sondern
 ein menschliches. Ein paar Powermapper meinen, dass jede Beziehung
 von Objekten in der DB explizit mit Relationen modeliert werden müsse
 und treten dabei dei eigentliche Idee von OSM mit Füssen, nämlich
 dass OSM eine spatiale DB ist und keine relationale.
 Anstatt also zu überlegen, was man den Leuten alles
 verbieten müsste, sollten wir die Mapper besser darüber aufklären,
 warum ihre Relationsmania überflüssig und gefährlich ist.

 Jans Frage am Anfang dieses Threads macht insofern überhaupt keinen
 Sinn. Es ist komplett irrelevant, wie leicht oder schwer eine
 Relation zu verarbeiten ist. Die einzige Frage, die er sich stellen
 sollte ist die: ist die Relation wirklich nötig oder ist es möglich,
 meine Information auch in Form von einfachen Tags und geografischen
 Beziehungen in der DB unterzubringen. Die Antwort auf diese Frage
 ist eindeutig, dass es möglich ist, und damit sollte die Sache
 erledigt sein.

 Ähnliches gilt für Anwendungen, die hier in letzter Zeit diskutiert
 wurden. (Ich denke mit Schaudern an den Thread zum Eisenbahn-Tagging.)
 Redundanz ist kein Argument für Relationen. Ich weiss nicht, wie man
 es anders in einer spatialen Datenbank verarbeiten kann ist kein Argument
 für Relationen. Ich kann die Daten so leichter runterladen ist kein
 Argument für Relationen. Das einzige relevante Argument ist: es geht nicht
 anders[1]. Und das sollten wir allen Mappern klar machen. Wie es
 eine ungeschriebene on the ground-Regel gibt, sollten wir eine
 vermeide Relationen-Regel einführen und so oft wie möglich zitieren.

 Wenn wir es schaffen mehr Selbstdisziplin zu üben und Relationen auf
 eine Handvoll klar definierter Anwendungsfälle zu begrenzen, braucht
 es keine Änderung an der API.

 Gruss

 Sarah

 [1] Und bevor man mich jetzt zu sehr beim Wort nimmt: das schliesst
 auch die Fälle ein, wo es zwar anders ginge, aber nur von hinten
 durch die Brust etc.

 ___
 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] Relationen aus der Sicht der Auswertung - Segen oder Fluch??

On Tue, Jul 10, 2012 at 09:14:10AM +0200, Jo wrote:
 Obwohl ich sicher eine PostGIS DB installieren kann auf Linux oder Windows,
 ist das fuer mich viel Aufwand, nur zum bestimmen ob etwas in etwas anderes
 liegt. Auf Android gelingt das schon nicht mehr. Da bin ich dann froh wenn
 ich sowas nur abfragen kann mittels eine Relation.

Dann sollten wir weiter daraufhinarbeiten, dass es bessere Tools gibt, damit
man sowas leichter machen kann. Entweder in dem man diese Tools leichter bei
sich installieren kann oder indem es entsprechende APIs gibt. Dummerweise ist
es halt sehr schwierig solche Software so zu bauen, dass sie allgemein und
performant funktioniert. Und einer der Gründe, warum das so schwierig ist,
sind diese Relationen, die man in seinen Tools berücksichtigen muss...

 Auch um Daten, die hierarchisch eingetragen sind (ich denke jetzt an
 Collections von Netzwerke von Routes), herunterzuladen mit der Overpass API
 sind Relationen unschatzbar wertvoll.

Dummerweise funktioniert das so halt in der Praxis nicht. Erstens skaliert
es nicht, Du kannst nicht für alles, was Du je abfragen willst, Relationen
anlegen (Wege auf Friedhöfen in Frankfurt). Und zweitens erfassen die
Mapper das nicht sauber. D.h. Du bekommst im besten Fall einen Teil der
Daten. Für Dich mag das genug sein, für die meisten Leute, die OSM-Daten
ernsthaft einsetzen wollen, reicht das nicht.

Das alles sieht so einfach aus mit den Relationen für solche Nutzungszwecke,
aber es ist eine Illusion. Es erspart Dir die harte Arbeit nicht.

Jochen
-- 
Jochen Topf  joc...@remote.org  http://www.remote.org/jochen/  +49-721-388298


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

Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??

2012-07-10 Diskussionsfäden Frederik Ramm


Hallo,

On 07/10/12 09:14, Jo wrote:

Auch um Daten, die hierarchisch eingetragen sind (ich denke jetzt an
Collections von Netzwerke von Routes), herunterzuladen mit der Overpass API
sind Relationen unschatzbar wertvoll.


Das ist ein Missbrauch von Relationen, und wenn ich solche Sammlungen 
sehe, loesche ich sie.


Relationen sind *nicht* dazu da, um Objekte in praktische Eimer fuer 
das Herunterladen zu sortieren.


Siehe auch: 
https://wiki.openstreetmap.org/wiki/Relations/Relations_are_not_Categories


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] Relationen aus der Sicht der Auswertung - Segen oder Fluch??

2012/7/10 Frederik Ramm frede...@remote.org

 Hallo,


 On 07/10/12 09:14, Jo wrote:

 Auch um Daten, die hierarchisch eingetragen sind (ich denke jetzt an
 Collections von Netzwerke von Routes), herunterzuladen mit der Overpass
 API
 sind Relationen unschatzbar wertvoll.


 Das ist ein Missbrauch von Relationen, und wenn ich solche Sammlungen
 sehe, loesche ich sie.

 Relationen sind *nicht* dazu da, um Objekte in praktische Eimer fuer das
 Herunterladen zu sortieren.


Kein Problem. Musst du machen. Ich war dabei eine Qualitaetskontrolle
aufzusetzen so dass das Fahrradnetzwerk und die Buslinien korrekt behalten
bleiben koennen. Das funkzioniert aber nur wenn Leute meine Arbeit nicht
kaputmachen. Vielleicht ist das ganze dann doch zu viel Zeitverlust.

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

Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??


Hallo Jochen,

On 10.07.2012 08:13, Jochen Topf wrote:

Keiner hat je davon geredet, Relationen wegzuschmeissen. Es ging in dieser
Diskussion darum, dass es schwierig ist, mit Relationen zu arbeiten.


Das liegt weniger am Konzept Relation als an der Komplexität mancher 
Anwendungsfälle, die wir mit Relationen in der Datenbank abbilden. 
Softwaretechnisch sind Relationen unproblematisch, auch mit einem Perl-Skript 
und einem XML-Extrakt kann man die Member von geschachtelten Relationen recht 
einfach ermitteln. Problematisch ist in der Regel der Umgang mit den Daten, 
sowohl für den Mapper als auch für den Entwickler. Für den Entwickler ist eine 
Relation allemal komfortabler als einzelne Knoten und Wege, die über identische 
Tags verknüpft sind.


Auf der Mapper-Seite sehe ich das Problem in der Regel weniger im Datenmodell 
als im GUI des Editors. Wenn das Datenmodell die Realität und die Denkweise des 
Nutzers abbildet, dann versteht das auch jeder. Wer es nicht versteht, der hat 
auch den abzubildenden Anwendungsfall nicht verinnerlicht und sollte die Finger 
davon lassen, so wie ich von ÖPNV-Relationen. Aber dass eine Straße oder ein 
Wanderweg aus mehreren Abschnitten bestehen können, die man zusammenfasst und 
dass man den Namen nur einmal dem zusammengefassten Objekt zuweist, das versteht 
jeder. Wenn nicht, dann sollte er sich auf das Mappen von einfachen POIs 
beschränken.


Ein echtes Problem sehe ich beim GUI. Selbst für den relativ simplen Fall von 
Routen-Relationen gibt es mW keine vernünftige Unterstützung und ich könnte auch 
nicht definieren, wie so etwas aussehen könnte.


Das gilt auch auch für eine Tag-basierte Lösung. Je komplexer die Fälle werden, 
um so mehr (redundante) Tags muss Otto Normalmapper an jedes kleine Wegstück 
oder Gebäude hängen, Tags, deren Existenz, Syntax und Semantik sich ihm erst 
durch intensives Wiki-Studium erschließt. Man wird entgegenhalten: dann soll er 
diese Tags halt erst mal weg lassen, jemand, der es weiß, wird die dann schon 
erfassen. Dieser jemand ist dann aber sicher auch in der Lage mit Relationen 
umzugehen.


Solange es keine zufriedenstellenden GUI-Lösungen für die komplexen 
Anwendungsfälle gibt, taugt der Hinweis auf den Normalmapper weder als Argument 
für noch gegen Relationen. Hier kam ja schon der Vorschlag, wer ein neues 
Konzept vorschlage, möge auch den Algorithmus für die Auswertung liefern. 
Wichtiger wäre, dass er beschreibt, wie es im Editor so umgesetzt werden kann, 
dass auch IT-unbedarfte Nutzer damit umgehen können.


Gruß
Rainer


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

Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??

2012/7/10 Rainer Kluge rklug...@web.de

 Hallo Jochen,


 On 10.07.2012 08:13, Jochen Topf wrote:

 Keiner hat je davon geredet, Relationen wegzuschmeissen. Es ging in dieser
 Diskussion darum, dass es schwierig ist, mit Relationen zu arbeiten.


 Das liegt weniger am Konzept Relation als an der Komplexität mancher
 Anwendungsfälle, die wir mit Relationen in der Datenbank abbilden.
 Softwaretechnisch sind Relationen unproblematisch, auch mit einem
 Perl-Skript und einem XML-Extrakt kann man die Member von geschachtelten
 Relationen recht einfach ermitteln. Problematisch ist in der Regel der
 Umgang mit den Daten, sowohl für den Mapper als auch für den Entwickler.
 Für den Entwickler ist eine Relation allemal komfortabler als einzelne
 Knoten und Wege, die über identische Tags verknüpft sind.

 Auf der Mapper-Seite sehe ich das Problem in der Regel weniger im
 Datenmodell als im GUI des Editors. Wenn das Datenmodell die Realität und
 die Denkweise des Nutzers abbildet, dann versteht das auch jeder. Wer es
 nicht versteht, der hat auch den abzubildenden Anwendungsfall nicht
 verinnerlicht und sollte die Finger davon lassen, so wie ich von
 ÖPNV-Relationen. Aber dass eine Straße oder ein Wanderweg aus mehreren
 Abschnitten bestehen können, die man zusammenfasst und dass man den Namen
 nur einmal dem zusammengefassten Objekt zuweist, das versteht jeder. Wenn
 nicht, dann sollte er sich auf das Mappen von einfachen POIs beschränken.

 Ein echtes Problem sehe ich beim GUI. Selbst für den relativ simplen Fall
 von Routen-Relationen gibt es mW keine vernünftige Unterstützung und ich
 könnte auch nicht definieren, wie so etwas aussehen könnte.

 Das gilt auch auch für eine Tag-basierte Lösung. Je komplexer die Fälle
 werden, um so mehr (redundante) Tags muss Otto Normalmapper an jedes kleine
 Wegstück oder Gebäude hängen, Tags, deren Existenz, Syntax und Semantik
 sich ihm erst durch intensives Wiki-Studium erschließt. Man wird
 entgegenhalten: dann soll er diese Tags halt erst mal weg lassen, jemand,
 der es weiß, wird die dann schon erfassen. Dieser jemand ist dann aber
 sicher auch in der Lage mit Relationen umzugehen.

 Solange es keine zufriedenstellenden GUI-Lösungen für die komplexen
 Anwendungsfälle gibt, taugt der Hinweis auf den Normalmapper weder als
 Argument für noch gegen Relationen. Hier kam ja schon der Vorschlag, wer
 ein neues Konzept vorschlage, möge auch den Algorithmus für die Auswertung
 liefern. Wichtiger wäre, dass er beschreibt, wie es im Editor so umgesetzt
 werden kann, dass auch IT-unbedarfte Nutzer damit umgehen können.


Um es mich einfacher zu machen mit die Fahrradnetzwerke um zu gehen habe
ich in JOSM mapcss verwendet. So sieht es jetzt aus wie in Potlatch. Das
vorteil ist aber das ich die ein und ausschalten kann. Also wenn ich auf
Wandernetzwerke arbeite mach ich sichtbar, wenn Fahrradnetzwerke mit Knoten
schalte ich die ein. Und das geht auch gut mit OPNV-Netzwerke und ihre
Haltestellen. Fuer die Haltestellen kann man dan noch einfach waehlen ob
man die Namen oder die Zonen (zone numbers), oder etwas anderes sichtbar
machen will und sogar in unterschiedliche Farben.

Die Loesungen sind da, man muss die nur entdecken und benutzen. Jedenfalls
in ein Editor wie JOSM. In Vespucci fuer Android oder ILoE wird das
warscheinlich noch etwas laenger dauern...

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

Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??

On Tue, Jul 10, 2012 at 10:09:23AM +0200, Rainer Kluge wrote:
 On 10.07.2012 08:13, Jochen Topf wrote:
 Keiner hat je davon geredet, Relationen wegzuschmeissen. Es ging in dieser
 Diskussion darum, dass es schwierig ist, mit Relationen zu arbeiten.
 
 Das liegt weniger am Konzept Relation als an der Komplexität
 mancher Anwendungsfälle, die wir mit Relationen in der Datenbank
 abbilden. Softwaretechnisch sind Relationen unproblematisch, auch
 mit einem Perl-Skript und einem XML-Extrakt kann man die Member von
 geschachtelten Relationen recht einfach ermitteln. Problematisch ist
 in der Regel der Umgang mit den Daten, sowohl für den Mapper als
 auch für den Entwickler. Für den Entwickler ist eine Relation
 allemal komfortabler als einzelne Knoten und Wege, die über
 identische Tags verknüpft sind.

Sorry, aber das ist Unsinn. Hast Du schonmal die Daten für den ganzen Planeten
mit Perl-Skript verarbeitet und dabei die Relationen richtig aufgelöst und
das ganze dann immer aktuell gehalten, wenn sich die OSM-Daten ändern?

Auf kleinen Extrakten zu arbeiten und ab und zu mal dieses oder jenes zu
checken, das mag einfach sein. Aber mit wenigen Daten arbeiten ist immer
einfach. Hier geht es um Daten in der Größenordnung von hunderten Gigabytes
mit tausenden von Änderungen pro Minute. Da wird es dann plötzlich ziemlich
schwierig, mit den Daten vernünftig zu arbeiten.

Jochen
-- 
Jochen Topf  joc...@remote.org  http://www.remote.org/jochen/  +49-721-388298


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

Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??

2012/7/10 Jochen Topf joc...@remote.org

On Tue, Jul 10, 2012 at 10:09:23AM +0200, Rainer Kluge wrote:
On 10.07.2012 08:13, Jochen Topf wrote:
Keiner hat je davon geredet, Relationen wegzuschmeissen. Es ging in
dieser
Diskussion darum, dass es schwierig ist, mit Relationen zu arbeiten.

Das liegt weniger am Konzept Relation als an der Komplexität
mancher Anwendungsfälle, die wir mit Relationen in der Datenbank
abbilden. Softwaretechnisch sind Relationen unproblematisch, auch
mit einem Perl-Skript und einem XML-Extrakt kann man die Member von
geschachtelten Relationen recht einfach ermitteln. Problematisch ist
in der Regel der Umgang mit den Daten, sowohl für den Mapper als
auch für den Entwickler. Für den Entwickler ist eine Relation
allemal komfortabler als einzelne Knoten und Wege, die über
identische Tags verknüpft sind.

Sorry, aber das ist Unsinn. Hast Du schonmal die Daten für den ganzen
Planeten
mit Perl-Skript verarbeitet und dabei die Relationen richtig aufgelöst und
das ganze dann immer aktuell gehalten, wenn sich die OSM-Daten ändern?

Auf kleinen Extrakten zu arbeiten und ab und zu mal dieses oder jenes zu
checken, das mag einfach sein. Aber mit wenigen Daten arbeiten ist immer
einfach. Hier geht es um Daten in der Größenordnung von hunderten Gigabytes
mit tausenden von Änderungen pro Minute. Da wird es dann plötzlich
ziemlich
schwierig, mit den Daten vernünftig zu arbeiten.

Deswegen brauchen wir auch das Ameisenarmee das wir sind. Dafuer habe ich
auch dokumentiert was ich gemacht habe. Ich habe es aber mit Python
innerhalb von JOSM aufgesetzt.
Es ist tatsaechlich unmoeglich fuer ein Person um alle Daten von der ganze
Welt richtig zu halten. Dafuer mussen wir alle zusammenarbeiten und das so
vernunftig moeglich tun. Relationen helfen uns dabei. 1000x Duplizierte
Daten sind viel schwerer richtig zu halten als Abstraktionen.

http://wiki.openstreetmap.org/wiki/User:Polyglot/Some_ways_to_simplify_editing_cycle_node_routes_with_JOSM

Hier koennt ihr sehen wie es aussieht mit mapcss:

http://wiki.openstreetmap.org/wiki/Cycle_Node_Network_Tagging#Split_nodes_and_the_tentacles_extending_the_routes_to_connect_them

Die Mittel um Relationen auszuwerten und visualiesieren im Editor sind
tatsaechlich da.

Und dies geht ueber die Qualitaetskontrolle:

http://wiki.openstreetmap.org/wiki/Quality_control_with_Python_script_in_JOSM

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

Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??


On 10.07.2012 10:49, Jochen Topf wrote:

On Tue, Jul 10, 2012 at 10:09:23AM +0200, Rainer Kluge wrote:

auch
mit einem Perl-Skript und einem XML-Extrakt kann man die Member von
geschachtelten Relationen recht einfach ermitteln. Problematisch ist
in der Regel der Umgang mit den Daten, sowohl für den Mapper als
auch für den Entwickler. Für den Entwickler ist eine Relation
allemal komfortabler als einzelne Knoten und Wege, die über
identische Tags verknüpft sind.


Sorry, aber das ist Unsinn. Hast Du schonmal die Daten für den ganzen Planeten
mit Perl-Skript verarbeitet und dabei die Relationen richtig aufgelöst und
das ganze dann immer aktuell gehalten, wenn sich die OSM-Daten ändern?


Ich kann mir kaum vorstellen, dass jemand auf die Idee kommt, so etwas mit Perl 
zu machen. Wenn du auf dem Planetfile aufsetzst und die für solchen Fälle 
geeigneten Tools benutzst, dann wird der Vorteil durch Relationen erst recht 
deutlich. Es ist immer einfacher, die Relation Goethestraße in einer Gemeinde 
zu suchen und dann die einzelnen Members abzuarbeiten als sämtliche 
Goethestraßen in der Gemeinde zu suchen und zu prüfen, ob die vielleicht 
zusammenhängend sind bzw. nahe beieinander liegen. Insbesondere dann, wenn du 
auch noch berücksichtigst, dass es keine Seltenheit ist, dass es mehrere Straßen 
mit demselben Namen in einer Gemeinde gibt.


Rainer


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

Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??


On 10.07.2012 10:24, Jo wrote:

Die Loesungen sind da, man muss die nur entdecken und benutzen. Jedenfalls
in ein Editor wie JOSM. In Vespucci fuer Android oder ILoE wird das
warscheinlich noch etwas laenger dauern...


Das zeigt doch, dass diese Lösungen nicht für den Normalmapper ohne besondere 
IT-Kenntnisse verfügbar sind. Der benützt Potlatch2, wenn es hoch kommt Josm 
ohne Plugins.




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

Re: [Talk-de] ergänzende Frage - bevor diese vergessen wird...


On 10.07.2012 07:39, Jochen Topf wrote:

Es ist eben enorm schwierig so ein Programm zu schreiben. Weil es eben lauter
verschiedene Relationen gibt und verschiedene Interpretationen, welche Tags
genau wo hingehören usw.


Jans Frage bezieht sich explizit auf Relations/Proposed/Buildings, also einen 
ganz speziellen Typ von Relation. Dafür sucht er eine C-Funktion, die ihm für 
einen bestimmten Bereich die Adresse und evtl, andere Tags von der 
Gebäuderelation auf die Teilgebäude, Eingänge und POIs überträgt. Das Ergebnis 
soll wahrscheinlich eine XML- oder PBF-Datei sein, welche nicht mehr die 
Realtion dafür aber alle Members mit den zusätzlichen tags enthält.


Ich verstehe nicht, wo da das Problem sein soll und warum er das nicht selber 
macht oder einer aus der Lübecker Gruppe.


Gruß
Rainer


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

Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??

2012/7/10 Rainer Kluge rklug...@web.de

 On 10.07.2012 10:24, Jo wrote:

 Die Loesungen sind da, man muss die nur entdecken und benutzen. Jedenfalls
 in ein Editor wie JOSM. In Vespucci fuer Android oder ILoE wird das
 warscheinlich noch etwas laenger dauern...


 Das zeigt doch, dass diese Lösungen nicht für den Normalmapper ohne
 besondere IT-Kenntnisse verfügbar sind. Der benützt Potlatch2, wenn es hoch
 kommt Josm ohne Plugins.


Das zeigt das jemand mit IT-kenntnisse aussuchen muss wie das funkzionieren
kann. Wenn der das dan dokumentiert, dann ist es aber relative einfach fuer
jeder der lesen kann und Instruktionen folgen will, das auch zu machen.

Das ist jedenfalls was ich vor einege Monaten gemacht habe (investigate and
document). Jedenfalls ist der Welt kompliziert, also kann die
Darstellung/Representation auch nicht total unkompliziert sein und werden
Abstraktionen immer notwendig sein. Relationen helfen uns dabei.

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

Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??

2012-07-10 Diskussionsfäden aighes


Ihr redet ein klein wenig an einander vorbei.

Die Relation ist einfacher. Aber eben nicht alle Goethestraßen sind auf 
diese weise eingetragen und für diese muss man dann trotzdem den 
komplexeren Algorithmus entwerfen.


Wenn man also gleich nur den komplexeren Algorithmus nutzt, spart man 
sich das auslesen der Relation.


Viele Grüße,
Henning


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

Re: [Talk-de] ergänzende Frage - mein Ziel

2012-07-10 Diskussionsfäden Jan Tappenbeck


Am 10.07.2012 11:54, schrieb Rainer Kluge:

On 10.07.2012 07:39, Jochen Topf wrote:

Es ist eben enorm schwierig so ein Programm zu schreiben. Weil es eben
lauter
verschiedene Relationen gibt und verschiedene Interpretationen, welche
Tags
genau wo hingehören usw.


Jans Frage bezieht sich explizit auf Relations/Proposed/Buildings,


= sollte aber auch erst einmal als Beispiel dienen; ist aber auch 
gleichzeit mein aktuelles Problem.



also einen ganz speziellen Typ von Relation. Dafür sucht er eine
C-Funktion, die ihm für einen bestimmten Bereich die Adresse und evtl,
andere Tags von der Gebäuderelation auf die Teilgebäude, Eingänge und
POIs überträgt. Das Ergebnis soll wahrscheinlich eine XML- oder
PBF-Datei sein, welche nicht mehr die Realtion dafür aber alle Members
mit den zusätzlichen tags enthält.



= genau


Ich verstehe nicht, wo da das Problem sein soll und warum er das nicht
selber macht oder einer aus der Lübecker Gruppe.


= a.) nicht können
= b.) keinen im Lübecker Stammtisch
= c.) frage erst einmal ob es soetwas gibt bevor ich das Rad neu erfinde.

Gruß Jan :-)


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

Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??


Hi,


Am 10.07.2012 08:33, schrieb Sarah Hoffmann:

Kannst du konkrete Beispiele nennen von Anwendern, die irgendeiner Relation
ausser den drei wirklich gebrauchten (Routen, Abbiegerelation,
Multipolygon) nachweinen würden?


Es ist deine Ansicht, dass dies die drei einzigen sind, die wirklich 
gebraucht werden.  Du kennst das Wiki, Leute haben sich über Jahre 
Gedanken darüber gemacht, wo deren Meinnung nach Relationen sinnvoll 
sind.  Ich denke nicht, dass Du intensiv genug geforscht hast, um deren 
Arbeit mit ein bisschen m.E. zu entkräften.  Ich persönlich habe in 
letzter Zeit waterway, bridge, site Relationen genutzt.


Speziell bei den waterways erhältst Du z.B. keinen eindeutigen Strang 
von Quelle zur Mündung.  Auch eine Relation garantiert da nichts, aber 
wenn ich mir vorstelle, dass ich mir einen Hauptflusslauf erstmal Weg 
für Weg über Overpass oder einer lokalen DB ziehen müsste, mit einem gut 
möglichen overhead von 2/3 falschen Positiven, kommt mir das Grauen.  
Z.B. gibt es viele gleich benannte Nebenarme, Fahrrinnen, Schleusenarme, 
etc. - ich verlasse mich auch nicht auf die Relation allein, verwende 
sie aber als Ausgangspunkt.  Weiterhin siehst Du z.B. am Rhein-Delta, 
dass ein Tag-Matching+Node-Verbindung nutzender Algorithmus versagen 
wird, denn in den Niederlanden heißt der Rhein schonmal Rijn und fließt 
über Waal, Lek, etc. ab.  Das sind nur ein paar der Spezialitäten, die 
mir hier anwendungsspezifisch einfallen, es gibt sicher 'zig andere, 
aber nicht jeder hat die Zeit und die Muße auf dieser Liste gegen den 
Minimalismus anzukämpfen.




Wie Jochen bereits gesagt hat, muss man für die meisten Sachen den
Fall ohne Relationen ohnehin implementieren, weil es dieser Fall
immernoch der häufiger gebrauchte ist.


Ja, aber er ist die klar schlechtere Approximation gegen eine 
gewissenhaft gepflegte Relation.  Im Prinzip sollte das Fallback-Methode 
sein.  Ich stimme zu, dass es für viele Relationstypen Nachholbedarf bei 
der Spezifikation gibt, um etwa einen ähnlich guten Dokumentationsgrad, 
wie bei den MPs zu erreichen.



Relationen sind wesentlich leichter versehnlich kaputt zu machen als 
Nodes, Wege und Tags, weil sie unsichtbar im Hintergrund herumlungern 
und man nicht sofort sieht, dass man da etwas ändert. 


Mit der von Dir erstellten Cycling-Map (Kompliment übrigens) weißt Du 
doch, wie man sie sichtbar macht.  Ich finde nicht, dass die 
Unsichtbarkeit ein Argument gegen Relationen ist und finde umgekehrt, 
dass z.B. auch nicht verbundene Nodes wenn sie Nahe beieinander oder 
aufeinander liegen, schwer identifizierbar sind.  Zudem werden die 
Routen auch in Editoren visualisiert, das kam auch nicht über Nacht.  
Visualisierungen für andere Relationen werden auch kommen, je nach Bedarf.



Wenn du dir zuviel dieser Freiheiten herausnimmst, schränkst du 
gewaltig die Freiheiten der anderen Mapper ein. Siehe oben. Relationen 
sind in erster Linie ein Hindernis für deine Mitmapper. Es geht nicht 
darum, 'einheitlich' zu mappen, es geht darum, das ganze so einfach 
wie möglich zu halten, damit es für alle verständlich bleibt. 
Ausserdem sind Relationen ein Motivationskiller, wenn es darum geht 
Fehler zu korrigieren. Wer mag schon einen Weg anfassen, der Mitglied 
in 15 Relationen ist. Ein Weg mit 15 kryptischen Tags ist zwar auch 
ein bisschen lästig, aber normalerweise kann man die Tags einfach 
ignorieren, frei nach dem Motto 'leben und leben lassen'. 


Das ist total subjektiv.  Verlege ich den Weg mit 15 kryptischen Tags, 
ohne mir deren Inhalt anzuschauen, entstehen Fehler in evtl. größerem 
Maße, als wenn jemand Relationen bricht, die ein anderer nachpflegt.  
Natürlich bedeutet das alles Aufwand, der vergrößert sich aber ohne 
Relationen nur.  Ich bin der Auffassung, dass in Gebieten mir hoher 
Datendichte und evtl. auch vielen Relationen es unabdingbar ist, dass 
sich ein Mapper Gedanken macht, /was/ er /wie/ ändert.  Ob er da, für 
den Fall er macht sich keine Kopf, 15 Relationen bricht oder 15 
kryptische Tags dorthin verlängert, wohin sie nicht gehören, spielt eine 
untergeordnete Rolle.  Es geht immer zu Lasten derer, die gewissenhaft 
arbeiten.  So ist das nunmal - wie sagtest Du:  das ist kein technisches 
Problem, sondern ein menschliches..




Für mich bedeuten Relationen Flexibilität - u.U. oft auch, dass ein und
der gleiche geografische Sachverhalt eben vielfältig modelliert werden
kann.  Warum begreifen wir das nicht weiterhin als Chance?  Warum wird
stattdessen der Perfektionismus in primitiveren, unstrukturierten Daten
gesucht, wie es Knoten und Weg nunmal sind?

Geografische Sachverhalte sollte man über Geometrie ausdrücken und
nicht durch irgendwelche künstlichen Strukturen. Natürlich könnten
wir für jede Bushaltestelle eine Relation erstellen, die besagt, ob
sie jetzt rechts von der Strasse liegt oder links. Aber was ist der
Sinn? Diese Information ist bereits in der DB, das heisst die Relation
bringt absolut nichts.


Siehe unten, Beispiel Liste

Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??


Am 10.07.2012 09:43, schrieb Frederik Ramm:
Das ist ein Missbrauch von Relationen, und wenn ich solche Sammlungen 
sehe, loesche ich sie.


Relationen sind *nicht* dazu da, um Objekte in praktische Eimer fuer 
das Herunterladen zu sortieren.


Siehe auch: 
https://wiki.openstreetmap.org/wiki/Relations/Relations_are_not_Categories


Der Theorie dazu schließe ich mich an, nur wenn die Praxis so aussehen 
soll, dass jeder, der einen längeren Wasserlauf, das Netz der 
Bundesstraßen, etc. laden will, Overpass kennen, lernen und nutzen muss, 
um diesen praktischen Eimer zu vermeiden, funktioniert das /praktisch/ 
nicht.


Die Leute legen diese Eimer an, weil es praktisch ist und weil sie keine 
Alternativen kennen / haben.  Nicht jeder legt sich einen planet dump 
auf seinen Rechner und bastelt sich anschließend seine persönlichen 
Anfragen.


Es ist unpraktisch größere Gebiete als bounding box zu laden, wenn man 
doch nur sehr wenige Features darin braucht.  Deshalb existieren solche 
Sammlungen.  Der Sache quasie mit dem Feuerlöscher hinterherzulaufen, 
ist auf Dauer ebenso unpraktikabel.  Was fehlt sind Alternativen


- vielleicht ein paar Presets an Overpass-Queries für die 
häufigsten, falsch angelegten Relationen in den Editoren


Anstatt die falsch angelegte Relation einfach zu löschen, verschiebt 
man sie.  Z.B. könnte unter Verwendung der gleichen ID ein 
Overpass-Preset angelegt werden.  Damit wäre das ein echter Ersatz für 
die Relation-ID.  Hinter der Preset-ID


   - e.g. overpass-api.de/api/preset/12345

stünde dann eine (Overpass-)Anfrage, die den Inhalt generiert, den die 
unerwünschte Relation gehabt hätte.



Damit hätten wir auch gleich ein hübsches Kriterium, wann eine Relation 
überflüssig ist - ganz grob:  lässt sie sich durch ein Overpass-Preset 
ersetzen (ohne das Overpass in der Flut der Anfrage sinkt), ist sie 
überflüssig.




Gruß
Christian

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

Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??

2012-07-10 Diskussionsfäden Frederik Ramm


Hallo Christian,

  manchmal frage ich mich bei Deinen Beitraegen, ob Du sie absichtlich 
so lang und vielschichtig machst, dass niemand darauf in Gaenze 
antworten kann, damit Du dann das letzte Wort hast ;)



Dennoch, es ist
ohne eine solche Relation (momentan) mitnichten wirklich einfach

 - mit seinem Lieblingseditor effizient alle Brücken entlang der
Elbe zu laden


...


 - eine einfache, in drei Minuten geschriebene Anfrage z.B. für die
Overpass API zu erstellen, die diese Brücken zurückgibt


...

Ich bin gern bereit, darueber zu diskutieren, ob und wenn ja welche 
Relationen noetig sind, um die Realitaet ausreichend zu beschreiben.


Ich bin aber nicht bereit, zu akzeptieren, dass Relationen als 
praktisches Downloadwerkzeug benutzt werden. Relationen sind keine 
Sammel-Eimer fuer komfortables Downloaden. Wenn das einreisst, haben wir 
in Nullkommanix ausser der Bruecken ueber die Elbe-Relation auch noch 
die Flussbauwerke an der Elbe und die Flussnahe Bebauung an der Elbe 
und die Uferflaechen der Elbe und was vielleicht sonst noch alles 
praktisch sein koennte.


Oft genug beobachte ich hier schon, dass irgendjemand in OSM Mist macht 
und andere dann fast reflexartig nachziehen, und nichtsahnend 
begruenden: Analog zur Relation 'Bundesstrassennetz in Deutschland' 
habe ich hier mal angefangen, die Kreisstrassen des Main-Tauber-Kreises 
in eine Relation zu packen... hrnn!


Also: Relationen, deren Hauptzweck das einfachere Abrufen der Daten ist, 
sind nicht ok. Und die von Dir angebrachte Begruendung andere Methoden 
sind halt zu schwierig mag zwar stimmen und sie koennte ein Grund 
dafuer sein, dass diese Relationen entstehen, aber sie ist keine 
*Berechtigung* fuer diese Relationen.


Ich bleibe dabei - reine Sammlungen gehoeren geloescht.

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] Relationen aus der Sicht der Auswertung - Segen oder Fluch??

2012-07-10 Diskussionsfäden Manuel Reimer


Christian Müller wrote:

Der Theorie dazu schließe ich mich an, nur wenn die Praxis so aussehen soll,
dass jeder, der einen längeren Wasserlauf, das Netz der Bundesstraßen, etc.
laden will, Overpass kennen, lernen und nutzen muss, um diesen praktischen
Eimer zu vermeiden, funktioniert das /praktisch/ nicht.


Warum? Was ist so falsch daran, mal bei den Wissenden nachzufragen, wie man X 
aus der DB fischen kann?


Um ehrlich zu sein, habe ich vor einiger Zeit auch mal mit dem Gedanken 
gespielt, eine Relation zu missbrauchen, um für eigene Zwecke gewisse POIs 
schnell zu holen. Es sprechen mehrere Punkte dagegen:


- Wenn die Relation von unwissenden verändert wird, dann bekomme ich die 
Infos, die ich wollte, nicht mehr.
- Ich müsste selber manuell die Relation aktuell halten. Also brav jeden neuen 
POI dort auch wieder reinwerfen. Ein passendes (X|Overpass)API-Query 
funktioniert automatisch und immer. Ich muss den neuen POI nur anlegen.
- Relation und schnell bestimmte Daten abrufen bedeutet, gerade bei 
unwissenden, häufig auch, dass die die normale API dafür missbrauchen wollen. 
Die ist für solche automatischen Abfragen aber nicht gedacht!


Gruß

Manuel


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

Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??

2012-07-10 Diskussionsfäden Manuel Reimer


Frederik Ramm wrote:

(Zugegeben: Genauso, wie wir Nutzer nicht zwingen sollten, ohne Not Objekte zu
logischen Konstrukten zusammenzufassen, so sollten wie sie auch nicht zwingen,
eine eigentlich zusammengehoerende Strasse in Stuecke zu hacken, bloss weil ein
Tempolimit kommt oder der Bus abbiegt...)


Gibt es denn dafür eine Alternative? Um das Tag Tempolimit auf 30 korrekt zu 
setzen, muss man die Straße doch zerschneiden, wenn nicht die gesamte Straße 
betroffen ist. Für die in Relationen angelegten Wanderrouten ebenfalls, denn man 
legt ja nur das Stückchen Weg in die Relation, auf dem die Route verläuft.


Gruß

Manuel


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

Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??

Am 10.07.2012 17:09, schrieb Frederik Ramm:
 Also: Relationen, deren Hauptzweck das einfachere Abrufen der Daten
 ist, sind nicht ok. Und die von Dir angebrachte Begruendung andere
 Methoden sind halt zu schwierig mag zwar stimmen und sie koennte ein
 Grund dafuer sein, dass diese Relationen entstehen, aber sie ist keine
 *Berechtigung* fuer diese Relationen.

+1  anders wollte ich das eigentlich auch nicht verstanden wissen. 
Dennoch wäre es wesentlich einfacher, die Ersteller solcher Relationen
davon zu überzeugen, es nicht zu tun, wenn es eine brauchbare, einfache
non-sql-hacking Alternative gäbe.  Ob die alternativlose Löschung auf
Dauer überzeugt, ist doch fraglich.  Ich denke, wenn es eine
Community-pflegbare Liste von Preset-Queries auf die ein oder andere
Weise auf Overpass geben würde, fänden sich genügend Leute, die helfen
categories aus der main db zu entfernen.

Allerdings bedeutet diese Umverteilung von Information (preset-query
statt explizite Sammelrelation) auch eine gewisse Dezentralisierung und
es ist mehr als fraglich, ob sich diese Verfahrensweise beim Umgang mit
gewünschten Kategorien dann außerhalb D verbreitet und auch dort
überzeugt.  Parallel zum planet dump bräuchte es dann auch einen
preset-query dump, um das mal etwas weiter zu spinnen.


Gruß

ps:  nein, ich schreibe vielschichtige mails nicht, damit die Leute
weglaufen..

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

Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??

Am 10.07.2012 17:56, schrieb Manuel Reimer:
 Christian Müller wrote:
 Der Theorie dazu schließe ich mich an, nur wenn die Praxis so
 aussehen soll,
 dass jeder, der einen längeren Wasserlauf, das Netz der
 Bundesstraßen, etc.
 laden will, Overpass kennen, lernen und nutzen muss, um diesen
 praktischen
 Eimer zu vermeiden, funktioniert das /praktisch/ nicht.

 Warum? Was ist so falsch daran, mal bei den Wissenden nachzufragen,
 wie man X aus der DB fischen kann?

Das kann ich Dir auch nicht abschließend beantworten.  Ich reflektiere
nur den durch mich wahrnehmbaren, aktuellen Stand der DB und versuche
Gründe zu finden, weshalb die deiner Meinung nach unwissenden in einer
Vielzahl von Fällen auf die Komplexität (oder Einfachheit) von X aus
der DB fischen verzichten und Relationen für Zwecke verwenden, die
jenseits dessen liegen, was von ihren Designern angedacht war.

Und Overpass funktioniert ja nun auch noch nicht ewig, vorher war zwar
das unflexiblere Xapi da, aber beides scheint nicht als Alternative zur
Sammelrelation wahrgenommen zu werden.  Es ist auch nicht das gleiche -
stell Dir vor, die Community des Wiki-Projekts Germany würde die
Bundesstraßen nicht über Relationen pflegen - im Wiki müssten sie nun
ellenlange Overpass-URLs angeben, um sich auszutauschen oder Templates
für Overpass bauen.  So wird stattdessen einfach das Template für die
Relationen wiederverwendet und man erhält eine Vielzahl von Links
obendrauf (remote josm link, relation analyzer, etc. pp.).  Es scheint
also eine ganze Menge Vorteile zu geben, Relationen zu missbrauchen,
anstatt Overpass-Queries hin- und herzuschieben.  Evtl. ändert sich das
jetzt mit der starken Verfügbarkeit von Overpass, wer weiß.

 - Relation und schnell bestimmte Daten abrufen bedeutet, gerade
 bei unwissenden, häufig auch, dass die die normale API dafür
 missbrauchen wollen. Die ist für solche automatischen Abfragen aber
 nicht gedacht!

Mir brauchst Du das nicht erzählen ;-)  Und das Argument nicht dafür
gedacht, nun ja, ich muss Dir nicht erzählen, dass Pudel und Handys in
Mikrowellen getrocknet werden?  Dass die Thermoskanne statt für
Heißgetränke auch zum kühl halten verwendet wird?


Gruß
Christian


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

Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??

Am 10.07.2012 18:02, schrieb Manuel Reimer:
 Frederik Ramm wrote:
 (Zugegeben: Genauso, wie wir Nutzer nicht zwingen sollten, ohne Not
 Objekte zu
 logischen Konstrukten zusammenzufassen, so sollten wie sie auch nicht
 zwingen,
 eine eigentlich zusammengehoerende Strasse in Stuecke zu hacken,
 bloss weil ein
 Tempolimit kommt oder der Bus abbiegt...)

 Gibt es denn dafür eine Alternative? Um das Tag Tempolimit auf 30
 korrekt zu setzen, muss man die Straße doch zerschneiden, wenn nicht
 die gesamte Straße betroffen ist. Für die in Relationen angelegten
 Wanderrouten ebenfalls, denn man legt ja nur das Stückchen Weg in die
 Relation, auf dem die Route verläuft.

imho gibt es dazu keine Alternative.  Es sei denn man verbietet Wege in
Relationen zukünftig und definiert auch die Routen nur über nodes - um
letztere wiederzuverwenden, bräuchte man einen Weg nicht zu zerhacken.

Relationen mit anonymen Punkten zu pflegen dürfte hingegen niemandem
Spaß machen, zudem wächst die Mitgliederzahl in Relationen.
Zugegeben, in Gebieten mit hohen Datendichten werden Wege so stark
zerhackt, dass der Abstand zur Nutzung der Einzelnodes ohnehin nicht
mehr groß ist.  Das betrifft aber gerade bei Routen vorzugsweise nur die
Teilabschnitte, die durch Städte verlaufen.  Über Land dürfte die
Einsparung der Listenlänge, dadurch dass way_ids statt node_ids
verwendet werden, enorm sein und bleiben.


Gruß
Christian

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

Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??

2012-07-10 Diskussionsfäden Peter Wendorff


Am 10.07.2012 19:12, schrieb Christian Müller:

[...]

Allerdings bedeutet diese Umverteilung von Information (preset-query 
statt explizite Sammelrelation) auch eine gewisse Dezentralisierung 
und es ist mehr als fraglich, ob sich diese Verfahrensweise beim 
Umgang mit gewünschten Kategorien dann außerhalb D verbreitet und auch 
dort überzeugt. Parallel zum planet dump bräuchte es dann auch einen 
preset-query dump, um das mal etwas weiter zu spinnen.
Ich halte das mit diesen Presets für gar keine so schlechte Sache, 
aber ich sehe darin absolut keine Notwendigkeit für eine preset-query.
Wenn, dann für einen komfortablen Overpass-Query-Editor, der das 
erstellen solcher Queries nach individuellen Wünschen erlaubt.


Mit Relationen für Bundesstraßen und ähnlichen Blödsinn gibt es ja (zum 
Glück) auch keine Sammlung von Relations-IDs, die man komplett 
herunterladen kann, sondern höchstens einzelne Relationen, die auf 
einzelnen Wikiseiten verlinkt sind oder so.
Ob da (im wiki) aber jetzt ein /browse/relation/#-link steht oder eine 
z.B. overpass-query, ist doch sch***-egal.


Gruß
Peter




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

Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??

2012-07-10 Diskussionsfäden Peter Wendorff


Am 10.07.2012 19:48, schrieb Christian Müller:

Am 10.07.2012 18:02, schrieb Manuel Reimer:

Frederik Ramm wrote:

(Zugegeben: Genauso, wie wir Nutzer nicht zwingen sollten, ohne Not
Objekte zu
logischen Konstrukten zusammenzufassen, so sollten wie sie auch nicht
zwingen,
eine eigentlich zusammengehoerende Strasse in Stuecke zu hacken,
bloss weil ein
Tempolimit kommt oder der Bus abbiegt...)

Gibt es denn dafür eine Alternative? Um das Tag Tempolimit auf 30
korrekt zu setzen, muss man die Straße doch zerschneiden, wenn nicht
die gesamte Straße betroffen ist. Für die in Relationen angelegten
Wanderrouten ebenfalls, denn man legt ja nur das Stückchen Weg in die
Relation, auf dem die Route verläuft.

imho gibt es dazu keine Alternative.  Es sei denn man verbietet Wege in
Relationen zukünftig und definiert auch die Routen nur über nodes - um
letztere wiederzuverwenden, bräuchte man einen Weg nicht zu zerhacken.

Sorry, aber jetzt wirds stumpf.
Jetzt willst du eine Relation benutzen, um eine geordnete Liste von 
Nodes zu erhalten, die dann im editor  am besten auch noch als Linienzug 
dargestellt wird?
Das haben wir schon, nennt sich way und ist genau das. Dafür würde es 
reichen, bewusst mehrere ways über die gleichen nodes zu legen - etwas, 
was auch heute schon möglich ist (und genutzt wird - und außerdem z.B. 
bei Wänden, die sich zwei benachbarte Gebäude teilen, IMHO sinnvoller 
sind als dafür Multipolygone zu missbrauchen, nur um diese trennwand 
nicht doppelt als way eintragen zu müssen).


Gruß
Peter

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

Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??

Am 10.07.2012 20:48, schrieb Peter Wendorff:
 Mit Relationen für Bundesstraßen und ähnlichen Blödsinn gibt es ja
 (zum Glück) auch keine Sammlung von Relations-IDs, die man komplett
 herunterladen kann, sondern höchstens einzelne Relationen, die auf
 einzelnen Wikiseiten verlinkt sind oder so.

Es wird hier argumentiert, dass eine einzelne Bundesstraßenrelation an
sich schon Blödsinn ist, da sie Wege sammelt, die durch eine einfache
ref=query ebenso erhalten werden können.  Ich bin gegen individuelle
Queries - wenn sie ein Ersatz für Sammelrelationen sein sollen, müssen
sie öffentlich und damit diskutier- und im Notfall auch änderbar sein. 
Eben so, wie die Sammelrelation auch öffentlich einseh- und änderbar ist.


 Ob da (im wiki) aber jetzt ein /browse/relation/#-link steht oder eine
 z.B. overpass-query, ist doch sch***-egal.

Aus Anwendersicht schon, soll auch so sein.  Aus Entwicklersicht
offenbar nicht.


Gruß
Christian

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

Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??

Am 10.07.2012 20:52, schrieb Peter Wendorff:
 Am 10.07.2012 19:48, schrieb Christian Müller:
 imho gibt es dazu keine Alternative.  Es sei denn man verbietet Wege in
 Relationen zukünftig und definiert auch die Routen nur über nodes - um
 letztere wiederzuverwenden, bräuchte man einen Weg nicht zu zerhacken.
 Sorry, aber jetzt wirds stumpf.
 Jetzt willst du eine Relation benutzen, um eine geordnete Liste von
 Nodes zu erhalten, die dann im editor  am besten auch noch als
 Linienzug dargestellt wird?

Der Vorschlag ist gar nicht mal von mir - er kam im Zusammenhang mit
ÖPNV-Relationen schonmal, weil sich deren Mapper beschweren, dass die
Relationen durch Geometrieänderungen der Wege häufig zerstört werden. 
Die Theorie ist, nur bestimmte nodes zu mappen und den Rest durch einen
Router erledigen zu lassen.

Ich stimme Dir zu, dass overlapping ways dem Nahe kommen.  Nur ist die
Fangemeinde von overlapping ways auch nicht besonders groß, da sie
ebenso wie mancher Relationstyp schlecht oder gar nicht visualisiert werden.

Aneinandergereihte Gebäude nutzen häufig overlapping ways, da stimme ich
Dir ebenso zu.  Eigentlich gibt es die Wand nur einmal, welche da durch
zwei Wege in OSM repräsentiert wird.  Das geschieht aus Bequemlichkeit,
nicht weil es logisch und/oder plausibel ist.  Streng genommen müßte ein
MP her, welches die Wand in Bezug zu den Gebäuden setzt, an denen sie
teilnimmt.  Wir zeichnen auch Ländergrenzen nicht doppelt.


Gruß
Christian



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

Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??

2012-07-10 Diskussionsfäden Peter Wendorff


Am 10.07.2012 21:03, schrieb Christian Müller:

Am 10.07.2012 20:48, schrieb Peter Wendorff:

Mit Relationen für Bundesstraßen und ähnlichen Blödsinn gibt es ja
(zum Glück) auch keine Sammlung von Relations-IDs, die man komplett
herunterladen kann, sondern höchstens einzelne Relationen, die auf
einzelnen Wikiseiten verlinkt sind oder so.

Es wird hier argumentiert, dass eine einzelne Bundesstraßenrelation an
sich schon Blödsinn ist, da sie Wege sammelt, die durch eine einfache
ref=query ebenso erhalten werden können.  Ich bin gegen individuelle
Queries - wenn sie ein Ersatz für Sammelrelationen sein sollen, müssen
sie öffentlich und damit diskutier- und im Notfall auch änderbar sein.
Eben so, wie die Sammelrelation auch öffentlich einseh- und änderbar ist.
Wenn ich einen overpass-link erzeuge wie (nicht geprüft, nur 
schematisch) [bbox=][highway][ref=B 7], dann kann man anhand !dieses 
Links! genausogut diskutieren wie anhand der relations-id 0815, die die 
gleichen Elemente enthält:
- Das Abfragen ist genauso einfach (wenn ich osm.org/browse/* mal 
ausnehme, das bricht nämlich gerade bei großen Relationen sowieso 
regelmäßig zusammen).
- Das Verteilen des Links ist genauso einfach, nämlich in beiden Fällen 
per CopyPaste
- Das Ändern des Inhalts ist einfacher: ich muss mich nämlich gar nicht 
darum kümmen, solange ich das ref-Tag richtig setze
- Das Ändern des Links ist auch nicht schwieriger; wenn man das 
überhaupt braucht (dürfte nur dann der Fall sein, wenn auf einmal z.B. 
die gerade neu eingetragene B 7 in Österreich zufällig die BoundingBox 
überschneidet)

Ob da (im wiki) aber jetzt ein /browse/relation/#-link steht oder eine
z.B. overpass-query, ist doch sch***-egal.

Aus Anwendersicht schon, soll auch so sein.  Aus Entwicklersicht
offenbar nicht.
Ich vermute, auch aus Entwicklersicht ist das egal - nur sind es oft 
nicht die Entwickler, die das ins wiki einpflegen, sondern Mapper, die 
es nicht anders kennen.


Übrigens verstehe ich ehrlich gesagt gar nicht, wofür man ernsthaft 
gerade eine Bundesstraße vollständig braucht: Für das Netz aller 
Bundesstraßen vielleicht - aber dann hab ich vermutlich auch mehr Power, 
weil ich damit ja irgendwas anfangen will; dann tut's die Datenbank mit 
'nem z.B. einmaligen Germany-Extrakt auch nicht mehr.
Fürs Routing und für die meisten Render-Aufgaben (Karten, 3D und alle 
anderen, die mir einfallen, brauche ich immer auch zusätzliche Daten.
Für eine ernstzunehmende Analyse muss ich mir auch angucken, was evtl. 
falsch ist oder rundrum liegt - also brauche ich auch da mehr/alle Daten.
(Bitte versteh das jetzt aber nicht als Ausflucht aus der Diskussion; 
die Frage stellt sich unabhängig vom Sinn und Unsinn solcher Relationen 
im Vergleich zu Tags)


Gruß
Peter

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

Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??