bzgl. amazon.com, frag’ doch mal auf talk-us, da findet sich sicherlich jemand, alternativ direkt beim Amerikanischen Chapter anfragen (osm-us).

Gruß Martin

@malenki: +1, disused:= also der Präfix ist auf jedem Fall im Vergleich zu einem zusätzlichen tag wie disused=yes zu bevorzugen, um Verwechslungen und Fehlinterpretationen zu reduzieren. Dass disused=yes für stations nirgends ausgewertet wird, stimmt allerdings nicht, selbst auf der Hauptkarte hatte ich in Erinnerung, dass das berücksichtigt wird, die Erinnerung hielt einer Überprüfung allerdings nicht Stand, das tag wird zwar bei Kanälen und Bahngleisen ausgewertet, bei Bahnhöfen aber in der Tat nicht.

@simon so there has been legal consultation? I am not asking to make it public, I have been hoping it might be accessible to foundation members, but I understand that this also might not be possible (in the end, everybody could become member of the foundation). I think what you could ask Apple for is a statement that they are not using ODbL data. This is not clear from their current attribution.

Have there also been talking with creative commons? I guess for them it is also very bad if open license violations don’t even get accused because of fear that the license could not hold up (there is a lot of data around, often from PAs, which is also licensed creative commons).

And yes, basically this is a confirmation, if you are big/powerful enough you must not care for license obligations, especially if you use the data from 2004 to 2012.

In all this we should not forget that also OSM is starting to become powerful, even to resist in a court case, we are steering towards 2 million users, and my guess is the publicity we would get for being sued by Apple for asking that they respect our open license would be immense and their moral damage so huge, that they will probably not do it (and you’d be astonished how many donations we’d get in order to be able pursue a potential court case).

@SOSM We don’t even know whether they are only using cc-by-sa data or not, because they don’t tell. The first thing we should ask them for is attribution according to the license they are using data under, so we can be clear on this point.

Secondly they are distributing our data also outside of the USA, so for Europe the data would still be protected under the database directive (and btw., as OSMF has its legal seat in London one could interpret that by downloading and re-distributing the data this would already be an agreement to the terms OSMF stated by that time for the use of the data. Unfortunately I don’t find those older terms on the OSMF-site which might have legal relevance for the users of pre-license-change data). OSMF as legal representative of OSM who has taken the effort of collecting the data would still have some rights also for the cc-by-sa data I guess, at least in jurisdictions with special database rights. In the end it was them suggesting that © OSM Contributors would be a sufficient attribution for works based on OSM and one might argue that the single contributors by contributing have accepted this.

As a third point we always said that we might at least win morally by telling the world that Company X is using our data which we intended to share under share-alike provisions without giving back. But obviously to make this happen we must at least point our finger at who does this, instead what happened was that they didn’t adhere to what the OSMF has in general asked for, for many years, from everybody, and OSMF, rather than complaning, was applauding.

I admit I am not a lawyer. Has someone in the past 2 years ever asked for legal advice on the issue of Apple using our data, and if yes, where is the documentation of the outcome?

The lesson I have personally learned from the proceedings of the past 2 years: OSMF is not showing itself prepared or even willing to fight for correct attribution of the data taken from OSM. Apple is now using our data for almost 2 years in a major product of theirs (Apple Maps, part of their mobile and desktop OS) and still they are not attributing correctly (they do not confirm our copyright, they do not even mention the license (which has always been an obligation under all OSM licenses), they do not tell where they are using our data so people can’t make use of the share alike rights that the license grants).

What has happened in 2 years? Almost nothing. On 7th of April 2012 the board has documented in the minutes of an extraordinary meeting with the title “Handling legal issue with Apple” [1]: “The board feels that due to the importance and timeliness of the current issue and due to the heavy workload of the license change that LWG hand off the Apple issue to the Board to pursue.”

Months later the case was returned to LWG. Until now the only change to the attribution they give (2 links away from the map, 1st link is “legal”, second is “data from TomTom and others”, almost at the bottom of a long list there is OSM) is that there is now a rough time span for the data (2011/2012), which doesn’t even allow to determine which license they would have to indicate (as from 2012 there is ODbL and cc-by-sa2.0 data available, maybe they even mixed the 2? They alone know…). This is not your small FOSS project or grocery website, this is a major IT company with hundreds of millions of distributed copies of their software! They do ignore almost every obligation we have set up for the use of our data and nothing (apparently) happens, OSMF even welcomed them in 2012 [2] and no word of incorrect attribution in the blog post ;-)

[1] https://docs.google.com/document/pub?id=16E0l4NdeMkUqgEe_mPC78tJ9yPQHUuRZYNtapBEM2K4 [2] http://blog.osmfoundation.org/2012/03/08/welcome-apple/

We should map what is the reality. In some jurisdictions the numbers mark an entrance, in others they are assigned to an area (usually a parcel or a building). It is not always clear where the number applies to, if in doubt, use a node, but if you know the exact area a housenumber applies to it is better to put the number on this area. Using areas has the advantage that you can see the actual extension and you can infer the number for the included elements/occupants.

you have a good point when you mention that actually almost nobody can release his contributions into the PD, because it will most likely be tainted by the existing ODbL data around it (exceptions might be editing in an empty area or surrounded by other PD data)

Bitte nicht blind Verbindungen herstellen, wenn Ihr die Stellen nicht kennt. Es gibt auch viele Stellen, wo man im echten Leben nicht durchkommt, zumindest nicht mit dem Auto, oft aber auch nicht mal zu Fuß (unterschiedliche Höhenebenen). Klar, das ist dann nicht besonders detailliert gemappt, wenn da nur 2 nicht verbundene Straßen sind und nicht z.B. ein Fußweg, ein fence, eine retaining_wall, etc. aber ohne Ortskenntnis geht das halt nicht. Falsche Verbindungen sind genauso schlecht wie nicht verbundene Straßen, die eigentlich verbunden gehören.

how many points did you measure? I fear that the differences aren’t simple offsets but more complex, due to the way this imagery is produced.

Nice tutorial, but it’s not working only with flickr, basically you can use any image sharing platform, my favorite is 23hq.com which let’s you download the full versions of your images also after you stopped paying (it’s 20EUR a year for unlimited access or free for 30 uploads a month). You can also bulk download all images (or a subset), their API is the same as Flickr’s (or as Flickr’s was some time ago).

areas should not share nodes with highways, because the highway is representing the center of the road, and its borders are only implicit (add half the width to the center line), while areas are drawn at their real limits, so they shouldn’t have common nodes with the center of highways. If you unify them it reduces information and makes further editing more complicated.

Please don’t unify adjacent landuses, when there is a gap in between them i.e. the gap is there in reality because there is a way or path or scrub, a waterway, sand or something else that isn’t a field in the case of landuse=farmland). You are removing details that convey information. The landuses should share nodes if the have a common border (or better use multipolygons in case the shared way has more than very few nodes).

IMHO streets should not have a landuse (or should have an explicit street-landuse). This is also how reality deals with this: streets are not part of the parcel land, they are usually land that is not part of a parcel.

lass Dich nicht abschrecken, einfach mal abwarten und weitermachen (oder woanders wenn Dir das dort nicht mehr gefällt), eines Tages wird man den Wert noch erkennen, auch wenn man lokal Dein Engagement nicht schätzt, die Welt dankt Dir!

I agree with Pieren, and I extend the critics: it seems to be a license infringement not to quote the license of the data (this is a requirement of both, cc-by-sa and ODbL). Also the wording does not contain a “copyright” or © sign, so our data contribution to their maps is basically quoted as if it was PD.

If the current licensing terms are a problem for mashups then this could be addressed by the mechanisms that the CTs installed: a vote by 2/3 of the active contributors. Nobody, not even the board of the OSMF, has the right to change the license (or sublicense under different terms) by other means.

Es ist nicht ganz eindeutig sicher, was die beste Methode ist, um Hausnummern und POIs zu erfassen. Die POI-Tags ans Gebäude zu hängen hat mehrere Probleme. Zum einen ist oft nicht der komplette Gebäudeumriss POI (dann wäre es falsch, die tags dort unterzubringen). Zum anderen ist das Gebäude was anderes als ein darin enthaltener POI (Nutzung). Von daher finde ich es nicht schlecht, wenn man diese beiden Objekte logisch trennt. Sonst ist bei vielen tags überhaupt nicht klar, worauf sie sich beziehen, z.B. start_date, name, operator, etc.

Bei Hausnummern wäre das beste (m.E.), das komplette Gebiet damit zu taggen, wo die Nummer gilt, d.h. in Deutschland oft das Grundstück (ist allerdings nicht bundeseinheitlich geregelt). Innerhalb dessen müsste man eigentlich nicht nochmal die Adress-tags wiederholen, es erleichtert aber vielen einfacheren Tools die Auswertung, wenn man es trotzdem tut.

Solange die Information richtig ist wäre es unnötig und sogar ein bisschen schädlich (unnötige Server-/Datenbanklast), diese doppelten Informationen wieder zu löschen, wenn man sie zusätzlich auf dem POI (node) getaggt hat (und dieser Node innerhalb der Fläche ist, die dieselben Adressinfos enthält). Wenn der POI allerdings durch eine area beschrieben ist, sollte er eher keine zusätzlichen (doppelten) addr-tags haben (m.E.), vor allem wenn die beiden areas nicht deckungsgleich sind, weil sonst ggf. unklar ist, wo die Adresse gilt, oder ob ein Fehler vorliegt.

Soweit bin ich mir Dir einverstanden, dass man Objekte trennen sollte, die nicht zusammen gehören, z.B. ein Haus von einem Restaurant. Auch nutze ich selbst meist Punkte für POIs. Ich halte es aber nicht für falsch, im Gegenteil für besser, einen POI ebenfalls als Fläche zumappen, sobald er eine gewisse Ausdehnung erreicht (die Grenze sehe ich ungefähr bei 1 m², d.h. Briefkästen oder Bankautomaten sind Punkte, Telefonzellen sind an der Grenze und was größer ist wird mit einer Fläche besser repräsentiert als mit einem Punkt).

Man kann übrigens die Objekte schön trennen, indem man nicht alle tags an den gleichen Umriss setzt, sondern pro Objekt auch in OSM ein Objekt verwendet (es bietet sich hier multipolygon an, das geht auch mit einem outer way ohne inner ways).

I also agree with you Pieren. Dynamic visibility of buttons should be opt-in not opt-out. I guess it might also be quite confusing to new mappers if the UI presents itself "dynamic" for the key features.

Schade, dass Du zu diesem Schluss gekommen bist, vielleicht überlegst Du es Dir ja nochmal. Kontaktieren finde ich auf jeden Fall richtig, auch wenn es etwas Mühe macht. Löschen und wiederzeichnen ist keine Option sondern Vandalismus. Ggf. sollte man solche Leute auch der DWG melden, wenn dahinter System steckt. Ohne konkrete Links bzw. Objekte ist es natürlich schwer, hier was zum konkreten Fall zu sagen.

Besides the legal aspects it is OK if the local mapping community agrees to the import and finds the imported data useful, suitable, accurate and up to date. If there is no local community to maintain that data it might be better not to
import it.
To get a better general impression what many people think about
imports and their impact on the project and on the community, see the
panel discussion that took place some weeks ago at SOTM-EU in Vienna:
streaming:
http://matterhorn.zserv.tuwien.ac.at/engage/ui/watch.html?id=Unscheduled-lecturetube-ei7-1310828485866
download:
http://sotm-eu.org/videos/ImportsPanel.ogg

Please also see the Wiki what the community expects how automated edits should be performed:
osm.wiki/Import/Guidelines
osm.wiki/Automated_Edits/Code_of_Conduct

Fürs Aufzeichnen von Tracks für OSM sind dedizierte GPS-Geräte m.E. weitaus besser geeignet als Smartphones. Neben der deutlich längeren Akkulaufzeit ist auch die Lagegenauigkeit i.d.R. viel besser. Derzeit gibt es lediglich bei den dedizierten GPS-Geräten lediglich für GARMIN Geräte Karten, da deren Format reverse engineered wurde, und vermutlich ändert sich an dieser Situation auch so schnell nichts. Persönlich würde ich ein Gerät ohne Touch-Screen bevorzugen, da man mit dedizierten Tasten m.E. viel besser und schneller navigieren kann (z.B. auch ohne hinzusehen) als mit dem Touch-Screen, aber das sind evtl. persönliche Vorlieben.