Re: [Talk-at] Fehlerhaftes Multipolygon über Wien?

[Martin Raifer]

Das dürfte mit http://www.openstreetmap.org/changeset/51891607 zu tun
haben (kein Multipolygon, sondern ein riesiges interkontinentales
Polygon). Der zugrundeliegende Fehler in den OSM-Daten wurde
mittlerweile schon behoben.

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

Re: [Talk-at] www.data.gv.at für Verwendung in OSM zugelassen?

[Martin Raifer]

Zur CC-BY Thematik siehe auch
https://blog.openstreetmap.org/2017/03/18/benutzung-von-cc-by-4-0-daten-in-openstreetmap/?lang=de
.

2017-04-13 17:50 GMT+02:00 Robert Kaiser :
> somehow_different schrieb:
>>
>> weitere Recherche hat folgendes zu Tage gefördert
>>
>> http://wiki.openstreetmap.org/wiki/Contributors#Austria
>>
>> Dort ist das Bundesportal data.gv.at ausdrücklich als mögliche Quelle
>> unter CC BY 3.0 angegeben. Wenn ich mir die Versionshistorie dieser
>> Seite anschaue, hat das User "Al."=Andreas Labres dort im Juni 2012
>> ergänzt. Bist das zufällig du?
>>
>> Dann ergibt sich folgende Frage: Was gilt nun hier? Ist jeglicher
>> Inhalt von data.gv.at zur freien Verwendung in OSM verfügbar, oder gilt
>> das nur für diejenigen Datensätze die selbst unter CC BY 3.0 dort zu
>> finden sind? Für Aufklärung bin ich sehr dankbar.
>
>
> CC-BY 3.0 und CC-BY-SA 2.0 sind ziemlich unterschiedlich zum behandeln.
> CC-BY-SA in jeglicher Form ist nicht mit der OSM-Datenbank kompatibel, da
> braucht man jedenfalls eine eigene Abmachung. SA würde bedingen, dass es
> unter keiner anderen Lizenz als CC-BY-SA weiter verwendet werden darf, und
> ODbL ist halt nicht das gleiche (obwohl im Sinn entsprechend).
> Bei CC-BY gibt es Diskussionen, weil es an sich kompatibel ist, aber es
> nicht 100% klar ist, ob die Nennung nur auf der Wiki-Seite genug ist, um das
> BY zu erfüllen, daher ist eine solche Klarstellung grundsätzlich einzuholen.
> Ob Andreas Labres die generell eingeholt hat, weiß ich nicht, aber normal
> ist es gut, ein dementsprechendes Schriftstück (kann auch elektronisch sein)
> zu verlinken, dann ist es klar.
>
> Zumindest ist das der Stand, den ich gehört habe, ich kann allerdings nicht
> für die DWG sprechen, bin nur "auch ein Mapper".
>
> Grüße,
> KaiRo
>
>
>
> ___
> Talk-at mailing list
> Talk-at@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-at

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

Re: [OSM-talk] multipolygon source tags preferred method

[Martin Raifer]

> I didn't know that iD doesn't allow you to set the source on the changesets 
> as somebody mentioned. If that is true, I see this as a shortcoming of iD 
> that should be fixed.

iD has changeset tag editing since a few weeks (which allows anyone to
set the changeset's source tag). It just waits to be rolled out on
osm.org with the next minor release of iD. See
https://github.com/openstreetmap/iD/pull/3898

On Tue, Mar 28, 2017 at 9:25 AM, Jochen Topf  wrote:
> On Mon, Mar 27, 2017 at 10:41:38AM +0200, Jochen Topf wrote:
>> On Mon, Mar 27, 2017 at 03:56:43PM +1000, nwastra wrote:
>> > I am unsure what is the preferred way or best practice to tag the source 
>> > for multipolygons.
>> > I currently put the source on the relation with all the rest of the tags, 
>> > and only adding tags to individual ways or inner polygons if they are also 
>> > part of a seperate entity like a fence or a body of water. I also include 
>> > the source with the uploaded change-set. This would seem to be ok when 
>> > adding a new mp relation.
>> >
>> > Should the source also be added to all the individual ways that make up 
>> > the outer and inner boundaries of each polygon?
>> > Is this also the preferred way when adding a new large mp relation that 
>> > does not currently exist?
>> >
>> > When replacing individual ways or splitting and altering part of a way 
>> > with updated data, adding the new source tag to those new ways would seem 
>> > best practice or is it sufficient to added the source to the change-sets 
>> > alone?
>> >
>> > Is the most sensible way to initially add the source tags to the relation 
>> > and change-set upload alone and from then on as individual parts are 
>> > amended, to add the source to just the updated/corrected ways and the 
>> > change-set on upload?
>> >
>> > I have not come across guidance for this on the wki yet.
>>
>> Putting the sources on the objects has been deprecated for a while. The
>> source should be put on the changeset only. If you are doing edits that
>> involve several different sources, it is best to split the changes up
>> into different changesets. Of course this is not always possible, then
>> you can also put several sources in the changeset source tag.
>>
>> Adding the source to the objects was deprecated, too fined-grained
>> source tagging simply doesn't make much sense. We can not track every
>> source for every node, way, or relation or the parts of them for every
>> tiny change that somebody does. In the end most data will have multiple
>> sources and figuring out what came from what can only be done going
>> through the changeset tags, not by looking at the tags on the data
>> itself.
>
> I probably shouldn't have used the word "deprecated", because there is
> no mechanism in OSM do deprecate anything. This is more "common
> practice" really. Martin has already described why source tags on
> objects don't work well. In theory they might or might not be a good
> idea, but in practice we have seen in OSM that they don't work. The
> source tag is just not updated in a way that makes it useful. Since we
> introduced changesets, we can do better: We put the actual data into OSM
> objects, but the meta-data that describes the why and how of the mapping
> we put into the changesets. (I didn't know that iD doesn't allow you to
> set the source on the changesets as somebody mentioned. If that is true,
> I see this as a shortcoming of iD that should be fixed.) This has the
> added benefit of putting the meta-data that is seldomly used on the
> changesets keeping the actual OSM objects lean and mean.
>
> Now regarding the splitting up of changesets for different sources. If
> you are doing different things this absolutely makes sense and, I would
> argue, is even necessary to be able to add good changeset comments,
> which you should always do. So if you come back from a mapping survey
> and add the data you collected outside with source "survey" and then go
> to a different part of the planet and add a few things from "bing",
> those should be two changesets. Of course, if you add the geometry of a
> road from Bing and the name from your survey, it makes total sense to
> add the source "bing;survey" or something like it.
>
> As always, there are few hard-and-fast rules in OSM. That's good because
> everbody can decide for themselves which arguments they find convincing
> and which advice to follow. So if you want to keep adding "source" tags,
> that's fine, too.
>
> Jochen
> --
> Jochen Topf  joc...@remote.org  https://www.jochentopf.com/  +49-351-31778688
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk

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

Re: [Talk-it] [Overpass-turbo] esporta query

[Martin Raifer]

Strano. È un bug dell' Overpass API. Ho aperto un issue su github:
https://github.com/drolbr/Overpass-API/issues/378

Nel frattempo questo sito dovrebbe ancora funzionare:
http://api.openstreetmap.fr/convert_form.html (o selezionate il serer
francese nelle impostazioni di Overpass turbo).

- Martin

2017-03-14 12:03 GMT+01:00 Marco :
> si, succede la stessa identica cosa anche a me
>
>
> Il 14/03/2017 11:56, Cascafico Giovanni ha scritto:
>
> Da alcune settimane, quando cerco di generare il link "converti in compatta"
> oppure "converti in OverpassQL" mi risponde con
>
> "unknown argument: --dump-compact-map-ql"
>
> Succede anche a voi?
>
>
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
>
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>

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

Re: [Talk-it] Nuovo menù su mappa OSM con funzione di reverse geocoding

[Martin Raifer]

> io però una volta usavo il tasto destro per avere l'indirizzo URL della tile
> e chiedere il render è stata tolta questa possibilità :-/

C'è la possibilità di premere  durante il clic per accedere il
menu contestuale originale del browser.

> si sa chi ha apportato questa modifica?

È stato l'utente "danstowell" su github:
https://github.com/openstreetmap/openstreetmap-website/pull/1030

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

Re: [Talk-it] la centrale unica emergenze 112 in Liguria usa mappe OSM

[Martin Raifer]

> C'è mica puzza di import?

Si trova[1] un paio di changeset con source="Comune di Genova" (per
esempio: http://www.openstreetmap.org/changeset/37199260).

[1] http://overpass-turbo.eu/s/mLV

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

Re: [Talk-at] LichtKarte lebt?

[Martin Raifer]

Hallo Borut,

das Projekt wird zwar nicht mehr offiziell von der Uni Heidelberg
weiterentwickelt[1], es gibt aber trotzdem Pläne, die für die Lightmap
verwendete DB neu aufzusetzen und dann wieder mit Updates zu
versorgen. Leider kann man momentan noch keine konkrete Zeitangabe
machen, ab wann das wieder aktiv sein wird.

[1] http://www.geog.uni-heidelberg.de/gis/online_en.html

Martin


2017-01-14 22:26 GMT+01:00 Borut Maricic :
> In der Wochennotiz Nr. 335 [1] wurde die LichtKarte erwähnt [2].
>
> Da es auf dessen Info-Seite steht, dass sie wöchentlich
> aktualisiert wird, bewegte mich das etwas Licht ins Großraum
> Leoben zu bringen. Leider merkte ich dann, dass die Karte
> mindestens drei Wochen lang nicht aktualisiert wurde.
> Anscheinend sind zwei von drei Entwickler nicht mehr mit dem
> Geographischem Institut Heidelberg [3] des Uni Heidelberg
> alliiert und die E-Mail Adresse des dritten, der eventuell
> noch da wäre, zeigt sich als nicht mehr existierend.
>
> Ist jemandem bekannt, ob dieses Projekt noch lebt?
>
> [1] http://blog.openstreetmap.de/blog/2016/12/wochennotiz-nr-335/
> [2] http://lightmap.uni-hd.de/?lat=47.380684280633=15.2764892578125=9
> [3] http://www.geog.uni-heidelberg.de/gis/mitarbeitende.html
>
>
> ___
> Talk-at mailing list
> Talk-at@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-at

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

Re: [Talk-it] Aiuto query Operpass-turbo

[Martin Raifer]

Si può cercare elementi via la propria id [1]: http://overpass-turbo.eu/s/lgt

[1] https://wiki.openstreetmap.org/wiki/Overpass_API/Overpass_QL#By_element_id


2017-01-14 12:13 GMT+01:00 mircozorzo :
> Ciao, chiedo un aiuto per costruire una query per l'estrazione di dei nodi di
> uno specifico tag a una certa distanza da una relazione data.
>
> Gli elementi che ho capito che dovrei usare sono la relazione individuata
>
>
> #a quale relazione faccio riferimento (non so come scriverlo)
>
> relation id=xx
>
>
> #quanto distante e e il tipo di amenità
> node(around:400)[ameity=drinking_water];
>
> out;
>
> Circa, ma la parte iniziale non so che sintassi usare.
>
> Ciao, Mirco
>
>
>
> --
> View this message in context: 
> http://gis.19327.n8.nabble.com/Aiuto-query-Operpass-turbo-tp5889404.html
> Sent from the Italy General mailing list archive at Nabble.com.
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it

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

Re: [Talk-at] historische Namen

[Martin Raifer]

>> Kann ein Gipfel in natura und in OSM nicht auch namenlos sein? ^-^
>> Dann wäre evtl. ein "noname=yes" Tag [1] angebracht.
>
> Dieses tag sehe ich generell skeptisch, weil es in der Realität nicht das
> bedeutet, was es bedeuten soll. Und zwar soll es bedeuten, dass das Feature
> wirklich keinen Namen hat. Tatsächlich bedeutet es aber nur, dass der Mapper
> keinen Namen in Erfahrung bringen konnte.

Wirklich? Mir wäre bis jetzt noch kein solcher Fall in OSM bekannt. In
jedem Fall wäre das aber meiner Meinung nach ein simpler Taggingfehler
(siehe [1]), und man sollte dann den jeweiligen Mapper über die
tatsächliche Bedeutung des Tags aufklären. :)

> Gerade in OSM haben wir die Verantwortung, altes Namensgut zu recherchieren
> und wiederzubeleben, das in herkömmlichen Karten auf Grund kleiner Maßstäbe
> weggeneralisiert wurde.

Diese Meinung teile ich nicht. OpenStreetMap sollte die gegenwärtige
Realität so gut und vollständig wie möglich wiedergeben. Altes
Namensgut ist sicherlich erhaltenswert, aber meiner Meinung nach
besser in einem speziellen Tag (wohl old_name [2]), oder externem
Projekt (z.B. Open Historical Map [3]) aufgehoben. Wir mappen ja auch
keine anderen historischen Informationen in OSM (kleines Beispiel:
aufgelassene Bahnstrecken mappen wir genau nur dann, wenn „die
Bahnstrecke […] als solches noch zu erkennen [ist]“ [4]).

Gruß
Martin

[1] http://wiki.openstreetmap.org/wiki/Key:noname
[2] http://wiki.openstreetmap.org/wiki/DE:Key:name
[3] http://wiki.openstreetmap.org/wiki/Open_Historical_Map
[4] http://wiki.openstreetmap.org/wiki/DE:Tag:railway%3Dabandoned

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

Re: [Talk-at] Peter Paul

[Martin Raifer]

Kann ein Gipfel in natura und in OSM nicht auch namenlos sein? ^-^
Dann wäre evtl. ein "noname=yes" Tag [1] angebracht.

[1] http://taginfo.osm.org/keys/noname

2016-12-28 0:18 GMT+01:00 Kevin Kofler <kevin.kof...@chello.at>:
> Martin Raifer wrote:
>> was ich nicht ganz nachvollziehen kann: Nur weil ein Name vor ca 200
>> Jahren möglicherweise gebräuchlich war, sollte man diesen nicht
>> zwingenderweise heute in OSM eintragen, oder?
>
> Wenn das der einzige Name dieses Gipfels ist, warum nicht? Sicher besser
> als, daß ihn jemand einfach nach sich selbst benennt.
>
> Kevin Kofler
>
>
> ___
> Talk-at mailing list
> Talk-at@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-at

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

Re: [Talk-at] Peter Paul

[Martin Raifer]

Zu:

> Da der Name Handleinsberg [historisch] belegbar ist werde ich diesen auf der 
> Karte eintragen.

sagst du:

> Finde ich gut.

was ich nicht ganz nachvollziehen kann: Nur weil ein Name vor ca 200
Jahren möglicherweise gebräuchlich war, sollte man diesen nicht
zwingenderweise heute in OSM eintragen, oder?

Oder habe ich dich hier falsch verstanden/zitiert?

Martin


2016-12-26 18:50 GMT+01:00 ScubbX <markus4mayr.li...@gmail.com>:
> Wie meinst du "wieso"? Ich meine das nur als Beobachtung?
>
>
>
> Am 2016-12-26 um 09:47 schrieb Martin Raifer:
>>
>> Wieso? Dieser historische Name scheint ja aktuell nicht mehr in
>> Verwendung zu sein?
>>
>>
>> 2016-12-24 18:55 GMT+01:00 ScubbX <markus4mayr.li...@gmail.com>:
>>>
>>> Finde ich gut.
>>>
>>> Im historischen Orts- und Riednamenverzeichnis vom BEV findet sich an
>>> dieser
>>> Stelle gar keine Bezeichnung.
>>>
>>>
>>> Am 2016-12-24 um 17:42 schrieb Liberaler Humanist:
>>>
>>> Auf einer Reproduktion des Franziszeischen Katasters findet sich etwas
>>> unterhalb der Name "Handleinsberg" ( Vgl.:
>>> https://www.wien.gv.at/kultur/kulturgut/plaene/franziszeisch.html - Man
>>> muss
>>> heranzoomen). Warum sich der Name nicht mehr in späteren Karten findet
>>> ist
>>> nicht ersichtlich, da der Gipfel wie am Commons-Foto ersichtlich als
>>> solcher
>>> klar erkennbar ist und auch auf einer topografischen Karte eine
>>> entsprechende Prominenz zeigt (
>>> https://opentopomap.org/#map=17/48.27224/16.31161 ). Da der Name
>>> Handleinsberg belegbar ist werde ich diesen auf der Karte eintragen.
>>>
>>> MfG, LH
>>>
>>>> Von: realadry <a...@gmx.at>
>>>> Datum: 24.12.2016 2:20 nachm.
>>>> Betreff: Re: [Talk-at] Peter Paul
>>>> An: OpenStreetMap AT <talk-at@openstreetmap.org>
>>>> Cc:
>>>>
>>>>> Hallo,
>>>>>
>>>>> Ich habe ein bisschen in online verfügbaren historischen Karten
>>>>> recherchiert und laut dieser Karte [1] von ca. 1941-1945, ist an dieser
>>>>> Stelle ein Gipfel markiert mit der Bezeichnung "Schwaben-Ws. 482".
>>>>> Ein Vergleich der Höhenlinien mit dem von Friedrich Volkmann geposteten
>>>>> screenshot [2], legt nahe, dass es sie hier um den selben Gipfel
>>>>> handelt. Die unterschiedliche Höhe (482 vs. 495) liegt vermutlich an
>>>>> damalig ungenauen Messmethoden bzw. Veränderung der Landschaft in der
>>>>> Zwischenzeit.
>>>>> Die Bezeichnung "Peter Paul" hingegen findet sich in keinem Dokument,
>>>>> weder historisch noch aktuell. Nur weil jemand diesen Namen auf OSM
>>>>> einträgt und sich dadurch verbreitet, macht es ihn noch lange nicht zum
>>>>> offiziellen oder gebräulichen Namen.
>>>>>
>>>>> Weiters: Das erste mal wurde der Gipfel in OSM auf "Peter Paul" benannt
>>>>> am 28.Juli 2012 [3]. Das Panoramio Bild wurde aber erst danach, am
>>>>> 10.August 2012, hochgeladen. Es ist also naheliegend, dass der Name des
>>>>> Gipfels auf dem Bild falsch aus OSM übernommen wurde.
>>>>>
>>>>> Ich hoffe das sind genug Beweise um zu zeigen, dass dieser Gipfel nicht
>>>>> "Peter Paul" heißt, auch wenn es jemand gerne so hätte. ;)
>>>>>
>>>>>
>>>>>
>>>>> [1]https://www.wien.gv.at/actaproweb2/benutzung/image.xhtml?id=kfGyc/iEt7fL65LzraHfwuM0+8OkdD4Jp25sfgC2ACs1
>>>>>
>>>>> [2]http://www.steige.info/austausch/screenshot_pp.png
>>>>>
>>>>> [3]http://www.openstreetmap.org/changeset/12521352
>>>>>
>>>>> Am 23.12.2016 um 18:50 schrieb grubernd:
>>>>>>>
>>>>>>> http://www.openstreetmap.org/note/510342
>>>>>>
>>>>>> endlich wieder einmal ein Henne-Ei-Problem.
>>>>>>
>>>>>> Meinung: war unbenannt, also ist eine Namensgebung absolut legitim, da
>>>>>> keinerlei Datenvandalismus vorliegt. mittlerweile finden sich einige
>>>>>> Hinweise [1][2], dass der Berg auch von anderen so genannt wird, also
>>>>>> wurde der Name angenommen. irgendwann ist es egal was einmal die Henne
>>>>>> und was das Ei war.
>>>>>>
>>>>>> ohne Worte für Ding

Re: [Talk-at] Peter Paul

[Martin Raifer]

Wieso? Dieser historische Name scheint ja aktuell nicht mehr in
Verwendung zu sein?


2016-12-24 18:55 GMT+01:00 ScubbX :
> Finde ich gut.
>
> Im historischen Orts- und Riednamenverzeichnis vom BEV findet sich an dieser
> Stelle gar keine Bezeichnung.
>
>
> Am 2016-12-24 um 17:42 schrieb Liberaler Humanist:
>
> Auf einer Reproduktion des Franziszeischen Katasters findet sich etwas
> unterhalb der Name "Handleinsberg" ( Vgl.:
> https://www.wien.gv.at/kultur/kulturgut/plaene/franziszeisch.html - Man muss
> heranzoomen). Warum sich der Name nicht mehr in späteren Karten findet ist
> nicht ersichtlich, da der Gipfel wie am Commons-Foto ersichtlich als solcher
> klar erkennbar ist und auch auf einer topografischen Karte eine
> entsprechende Prominenz zeigt (
> https://opentopomap.org/#map=17/48.27224/16.31161 ). Da der Name
> Handleinsberg belegbar ist werde ich diesen auf der Karte eintragen.
>
> MfG, LH
>
>> Von: realadry 
>> Datum: 24.12.2016 2:20 nachm.
>> Betreff: Re: [Talk-at] Peter Paul
>> An: OpenStreetMap AT 
>> Cc:
>>
>> > Hallo,
>> >
>> > Ich habe ein bisschen in online verfügbaren historischen Karten
>> > recherchiert und laut dieser Karte [1] von ca. 1941-1945, ist an dieser
>> > Stelle ein Gipfel markiert mit der Bezeichnung "Schwaben-Ws. 482".
>> > Ein Vergleich der Höhenlinien mit dem von Friedrich Volkmann geposteten
>> > screenshot [2], legt nahe, dass es sie hier um den selben Gipfel
>> > handelt. Die unterschiedliche Höhe (482 vs. 495) liegt vermutlich an
>> > damalig ungenauen Messmethoden bzw. Veränderung der Landschaft in der
>> > Zwischenzeit.
>> > Die Bezeichnung "Peter Paul" hingegen findet sich in keinem Dokument,
>> > weder historisch noch aktuell. Nur weil jemand diesen Namen auf OSM
>> > einträgt und sich dadurch verbreitet, macht es ihn noch lange nicht zum
>> > offiziellen oder gebräulichen Namen.
>> >
>> > Weiters: Das erste mal wurde der Gipfel in OSM auf "Peter Paul" benannt
>> > am 28.Juli 2012 [3]. Das Panoramio Bild wurde aber erst danach, am
>> > 10.August 2012, hochgeladen. Es ist also naheliegend, dass der Name des
>> > Gipfels auf dem Bild falsch aus OSM übernommen wurde.
>> >
>> > Ich hoffe das sind genug Beweise um zu zeigen, dass dieser Gipfel nicht
>> > "Peter Paul" heißt, auch wenn es jemand gerne so hätte. ;)
>> >
>> >
>> > [1]https://www.wien.gv.at/actaproweb2/benutzung/image.xhtml?id=kfGyc/iEt7fL65LzraHfwuM0+8OkdD4Jp25sfgC2ACs1
>> >
>> > [2]http://www.steige.info/austausch/screenshot_pp.png
>> >
>> > [3]http://www.openstreetmap.org/changeset/12521352
>> >
>> > Am 23.12.2016 um 18:50 schrieb grubernd:
>> > >> http://www.openstreetmap.org/note/510342
>> > >
>> > > endlich wieder einmal ein Henne-Ei-Problem.
>> > >
>> > > Meinung: war unbenannt, also ist eine Namensgebung absolut legitim, da
>> > > keinerlei Datenvandalismus vorliegt. mittlerweile finden sich einige
>> > > Hinweise [1][2], dass der Berg auch von anderen so genannt wird, also
>> > > wurde der Name angenommen. irgendwann ist es egal was einmal die Henne
>> > > und was das Ei war.
>> > >
>> > > ohne Worte für Dinge können wir nicht über diese Dinge reden, denken
>> > > und
>> > > uns austauschen. irgendjemand muss den ersten Schritt tun. unbenannte
>> > > Dinge nach dem Entdecker zu benennen ist ja durchaus eine grosse und
>> > > anerkannte Tradition in der Kartographie.
>> > >
>> > > grüsse,
>> > > grubernd
>> > >
>> > > [1] http://www.panoramio.com/photo/76813516
>> > > [2]
>> > >
>> > > http://www.gipfeltreffen.at/showthread.php?82202-Peter-Paul-Berg-494m-Wienerwald-(5620)/page2
>
>
>
> ___
> Talk-at mailing list
> Talk-at@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-at
>
>
>
> ___
> Talk-at mailing list
> Talk-at@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-at
>

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

Re: [Talk-it] Query elementi vicini

[Martin Raifer]

Sì:
* scuole con palestra: http://overpass-turbo.eu/s/kCQ
* scuole senza palestra: http://overpass-turbo.eu/s/kCO

2016-12-12 18:36 GMT+01:00 Cascafico Giovanni :
> Sarebbe possibile fare una query overpass che estragga scuole con o senza
> palestra nelle vicinanze? Anche in mancanza della relazione "site"?
>
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>

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

Re: [OSM-talk] Is Overpass falling far behind the database?

[Martin Raifer]

Which Overpass API server do you have configured in overpass turbo?
Because using the main instance (//overpass-api.de/api/), I don't seem
to get any outdated data…

On Tue, Nov 22, 2016 at 10:51 PM, Ben Discoe  wrote:
> Usually, using "overpass turbo" returns results which are very recent,
> usually less than an hour.
>
> https://wiki.openstreetmap.org/wiki/Platform_Status gives an Overpass
> status of "OK".
>
> However, for the past 2 days, results seem to be very out of date.
>
> As an example, this query: http://overpass-turbo.eu/s/kfp
>
> returns hundreds of nodes which were moved or deleted days ago.
>
> Is it a known issue of replication delay?
>
> Thanks,
> Ben
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk

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

[Talk-it-trentino] Toponomastica bilingue in Trentino

[Martin Raifer]

Ciao,

Segnalo che l'utente "fayor" ha modificato alcuni nomi bilingue in
Trentino (Valle della Fersina) lasciando solo il nome italiano nel
"name". Questo è il changeset:
https://www.openstreetmap.org/changeset/43173645. Non vedo che questa
modifica è stato discussa con la comunità locale, vero?

Non conosco personalmente la situazione locale, ma secondo wikipedia
“la toponomastica locale è bilingue: presenta il nome della località
prima in italiano, poi in mocheno. Tutto questo è regolamentato da una
legge e da un regolamento provinciale che concretizzano lo Statuto di
Autonomia delle Province Autonome di Trento e Bolzano che esprime la
parte sulle minoranze linguistiche”.
https://it.wikipedia.org/wiki/Pal%C3%B9_del_Fersina.

Cosa pensate?
Martin

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

Re: [Talk-it] State of the Map 2016 - WeeklyOSM in Italiano?

[Martin Raifer]

Voglio aggiungere che durante la SOTM, Manfred Reiter di “WeeklyOSM”
ha proposto l'idea di avere i news di OSM in ancora più lingue: Magari
sarebbe anche interessante avere un “Notiziario OSM” in Italiano?!
Interessante è il suo lightning talk
(https://youtu.be/yTJpUjuQZME?t=1h25m1s), dove ha mostrato lo
strumento che hanno sviluppato per facilmente gestire (e tradurre) i
news.

Ciao,
Martin

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

Re: [Talk-it] overpass xapi e wget

[Martin Raifer]

L'endpoint /xapi/* dell' Overpass API è stato disattivato dopo i
problemi del server due settimane fa: Qualcuno o qualcun' applicazione
fa troppe richieste tipo XAPI. Sarà disattivato fino a quando le
richieste diminuiscono a un livello "normale". Vedi
http://wiki.openstreetmap.org/wiki/Overpass_API/status per ulteriori
informazioni.

Nel frattempo puoi provare ad usare un server alternativo. Per esempio
questo dovrebbe funzionare al momento:
http://overpass.osm.rambler.ru/cgi/xapi/…

2016-08-31 16:11 GMT+02:00 emmexx :
> Ho usato per un po' di anni wget con il seguente url per ottenere i dati
> all'interno di un bbox:
>
> http://www.overpass-api.de/api/xapi?map?bbox=long1,lat1,long2,lat2
>
> Da qualche settimana mi appare un errore:
>
> HTTP request sent, awaiting response... 404 Not Found
>
> E' cambiato qualcosa nelle api? Bisogna usare altri sistemi. Ho guardato
> la documentazione online ma non ho visto avvisi che indicano che questa
> sintassi non e' piu' usata.
>
> grazie
> maxx
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it

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

Re: [Talk-it] Terremoto Rieti

[Martin Raifer]

Hey,

I took a quick look at the access statistics of the osm-tiles [1] and
it's really staggering how many people are looking at the area now on
OSM:

* pre event: http://imgur.com/a/ldUrg
* after earthquake: http://imgur.com/a/k45LX

What's astonishing is that the access numbers in the earthquake region
are currently on-par, if not larger, than what's otherwise only seen
in the largest cities: http://imgur.com/a/GAxG3

Ciao,
Martin

PS: I think, this is also reflected in today's tweet by
@trending_places:
https://twitter.com/trending_places/status/769087029506404352

PSS: The linked visualizations were done by my
osm-tile-access-log-viewer, whose code is here in case you'd like to
play around with it: [2]

[1] http://planet.openstreetmap.org/tile_logs/
[2] https://github.com/tyrasd/osm-tile-access-log-viewer

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

Re: [OSM-talk] How to check the historic popularity of a tag?

[Martin Raifer]

I'm currently working on exactly such a tool. I haven't gone out with
it yet, but a first working prototype is here:
http://taghistory.raifer.tech/, the source code and some
instructions/caveats are found on github:
https://github.com/tyrasd/taghistory.

I hope this fits your needs.

Best,
Martin

On Wed, Aug 24, 2016 at 7:30 PM, Christoph Hormann  wrote:
> On Wednesday 24 August 2016, Dave F wrote:
>>
>> I want to find out if a tag's usage is on the increase or decrease.
>> Is there a service which provides that data?
>>
>> I looked at Taginfo but couldn't see any obvious way to do it.
>
> Taginfo does not currently provide historic data but you are not the
> first to ask for it:
>
> https://github.com/joto/taginfo/issues/93
>
> The easiest way to determine this for low volume tags at the moment
> probably is via overpass API.  For high volume tags you need to process
> the history planet.
>
> --
> Christoph Hormann
> http://www.imagico.de/
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk

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

Re: [Talk-at] Maps.ME User: Private Nodes auf OSM-Server

[Martin Raifer]

> Getan hat sich von seiten der app-entwickler aber (noch?) nichts.

Also, zumindest in dem Punkt mit den falschen "name"-Tags scheint der
Entwickler bereits nachgebessert haben: Wenn ich das richtig sehe,
kann man seit einiger Zeit (zumindest auf Android) über die
Maps.Me-Editierfunktion nur noch die "name:xx"-Tags bearbeiten. Dabei
werden offenbar immer die Sprache des jeweiligen Benutzers und die
Sprache des jeweiligen Landes standardmäßig angezeigt. Weitere
Sprachen lassen sich über einen weiteren Klick hinzufügen. Ganz
optimal ist das jetzt allerdings auch nicht, weil man im
Bearbeiten-Formular jetzt den eigentlichen "name"-Tag gar nicht mehr
sieht, und man so als Anfänger evtl. einen eigentlich nicht unbedingt
notwendigen name:xx-Tag zu einem bereits benannten Objekt hinzufügen
könnte. (Aber besser als die Situation vorher ist es allemal.)

> Ich persönlich habe diese App nicht, und weiß somit nichts über deren 
> Funktionsweise.

Ich empfehle dringend, euch mal die App zumindest zu Testzwecken zu
installieren, um euch ein wenigstens grobes Bild über dessen
Bearbeitungs-Funktion zu machen. Das beugt Missverständnissen vor und
macht es um einiges leichter, mangelhafte Edits von Maps.Me-Benutzern
zu verstehen und zu erklären wie man es besser machen könnte.

> Es scheint aber, dass die App dem User nicht sagt, was mit den Daten passiert.

Das kann ich nicht bestätigen. Nach der ersten Bearbeitung eines
Objekts bekommt der User einen riesigen Dialog zu Gesicht, der in
großen Lettern erklärt: „Melden Sie sich an, damit andere Benutzer
Ihre Änderungen sehen können“. Vielleicht war das in älteren Versionen
der Software noch etwas weniger eindeutig formuliert.

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

Re: [Talk-it] Overpass-turbo, è in manutenzione?

[Martin Raifer]

>> L'unico server
>> funzionale al momento sembra essere quello su
>> http://api.openstreetmap.fr/oapi/
>
> Questo secondo mi da una pagina bianca con richiesta di permessi.
>
> Probabilmente va usato in alltro modo?

Ah, sì: In overpass-turbo, se vai nelle impostazioni, puoi scegliere
un server alternativo. Là puoi mettere questa URL (o scegliere il
terzo degli elementi nella lista auto-complete).

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

Re: [Talk-it] Overpass-turbo, è in manutenzione?

[Martin Raifer]

Ciao Simone

È in corso un attacco DDOS sul servizio hosting di overpass-turbo [1].
Non so quando il problema sarà risolto. Nel frattempo puoi usare
questa URL come alternativa: http://tyrasd.github.io/overpass-turbo/

Ma attualmente anche il server principale dell' Overpass-API ha dei
problemi (probabilmente un altro attacco), vedi [2]. L'unico server
funzionale al momento sembra essere quello su
http://api.openstreetmap.fr/oapi/

Martin

[1] https://twitter.com/ubernauten/status/767267625181339649
[2] http://wiki.openstreetmap.org/wiki/Overpass_API/status

2016-08-21 10:19 GMT+02:00 girarsi_liste :
> Quanto in oggetto, visto ieri sera ho provato a fare una ricerca
> semplice, e mi dava errore dopo un paio di minuti, stamattina vedo è di
> una lentezza esorbitante il caricamento.
>
> --
> Simone Girardelli
> _|_|_|_|_|_|_|_|_|_
> |_|_|_|_|_|_|_|_|_|_|
>
>
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it

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

Re: [Talk-it] Mappare un sentiero su OSM

[Martin Raifer]

Ciao Giulio.

Puoi spiegare di che tipo di "sentiero" si tratta? Sono dalla zona dove tu
hai mappato quel "cammino del beato Enrico", ma non ho mai sentito questo
nome e non ho mai visto delle cartelli segnalando a questo sentiero. E
neanche in internet si trova tanto a parte delle tue modifiche su osm [1].
Può essere che si tratta di un sentiero storico?

Tipicamente, in OSM noi mappiamo solo cose che sono verificabili sul posto
[2], che mi sembra di non essere il caso qui.

Ciao,
Martin

[1] https://duckduckgo.com/?q=%22Cammino+del+beato+Enrico%22
[2] http://wiki.openstreetmap.org/wiki/How_We_Map

2016-03-07 13:51 GMT+01:00 Giulio Pilotto :

> Ciao!
> Grazie mille a tutti dei consigli,davvero utili e soprattuto per la
> risposta immediata!
>
> @Gianmario : avevo avvistato le relazioni, però quando le aggiungo a ad
> alcuni tratti già tracciati, poi quando cerco sul OSM mi da solo un tratto
> alla volta.. c'è per caso un modo per visualizzare tutti i tratti che hanno
> la stessa relazione?
>
> @girarsi_liste: Grazie mille, siamo veneti, chiederò aiuto li!
>
> @mbranco: Interessante leggerò attentamente!
>
> Grazie a tutti,
> Giulio
>
> Il giorno 7 marzo 2016 13:35, mbranco  ha scritto:
>
>> Se può esserti utile, puoi leggere queste note che mi ero scritto quando
>> avevo affrontato lo stesso problema:
>> OSM_GuidaGpxRoute.pdf
>> 
>> Non sono un super-esperto di Osm/Josm, quindi ne approfitto per chiedere a
>> chi ne sa di più se ho fatto particolari errori e dove il documento è
>> migliorabile.
>>
>> Ciao!
>>
>>   Marco
>>
>>
>>
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://gis.19327.n5.nabble.com/Mappare-un-sentiero-su-OSM-tp5869267p5869281.html
>> Sent from the Italy General mailing list archive at Nabble.com.
>>
>> ___
>> Talk-it mailing list
>> Talk-it@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-it
>>
>
>
>
> --
>
>
> [image: --]
>
> Giulio Pilotto
> [image: http://]about.me/giuliopilotto
> 
>
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

[Talk-it-southtyrol] Open data portal South Tyrol

[Martin Raifer]

Today, the open data portal of South Tyrol has been launched:

http://daten.buergernetz.bz.it/

It currently contains about 250 data sets of various types, some of
them could be interesting for enriching/checking/completing OSM. Some
of the geografical data data is also available on the "Geokatalog"
portal specially created for the province's geodata, which has been
online for a couple of months already:

http://geokatalog.buergernetz.bz.it/

Both the Geoportal and the new Open Data portal offer most of their
data under the very liberal CC0-license which is great, as it makes
reusing the data very easy. If you use the data for mapping or other
OSM-related stuff, I'd suggest to give an attribution to the data
source, for example by linking directly to the portal.

Read more about the new portal on the following press release:
http://www.provinz.bz.it/news/de/news.asp?news_action=4_article_id=525841

Happy mapping,
Martin


--
-- Forwarded message --
From: Dario Zontini 
Date: 2015-12-09 14:27 GMT+01:00
Subject: [Talk-it] Open data Alto Adige
To: openstreetmap list - italiano 


Segnalo che oggi è stato inaugurato il portale Open data Alto Adige

http://dati.retecivica.bz.it/it/

Dario Zontini

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

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

Re: [Talk-at] Graphenintegrations-Plattform GIP als OGD

[Martin Raifer]

Evtl. könnte folgender Code für QGIS von Anita Graser hilfreich beim
Arbeiten mit dem bei GIP verwendeten Daten-Format IDF sein:

http://anitagraser.com/2015/07/23/open-source-idf-parser-for-qgis/

Gruß
Martin

2015-10-13 22:20 GMT+02:00 Simon Legner :
> Hallo,
>
> die Daten der Graphenintegrations-Plattform GIP sollen »ab Anfang 2016
> als Open Government Data (OGD) veröffentlicht« werden [1]. Es stehen
> bereits Testdaten für Testdatensätze in Wien (Bereich
> Westbahnhof/Gürtel) und Klagenfurt samt Dokumentation zur Verfügung
> [2]. Als Lizenz wird CC BY 3.0 AT verwendet werden.
>
> Grüße
> Simon
>
> [1] http://gip.gv.at/news/items/gip-als-open-government-data-ogd.html
> [2] http://gip.gv.at/ogd.html
>
> ___
> Talk-at mailing list
> Talk-at@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-at

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

Re: [Talk-at] geoimage.at: Reached counter limit

[Martin Raifer]

In der Zwischenzeit kann man auch die Orthofotos von basemap.at [1]
verwenden: Diese sollte eigentlich im Grunde die selben Luftbilder wie
geoimage beinhalten (evtl. sogar mit punktuell noch
aktuelleren/schärferen Bildern aus alternativen Luftbildquellen).
Zusätzlich läuft der Dienst ohne restriktive Nutzungseinschränkungen
und die Bilder sind unter einer offenen Lizenz verfügbar (CC-BY 3.0
AT).

Viele Grüße,
Martin

[1] 
http://www.basemap.at/application/index.html#{"center":[1445590,6059660],"zoom":8,"rotation":0,"layers":"000100"}
Verwendung im iD-editor: "Benutzerdefinierter Layer" mit folgender
Kachel-URL: 
http://maps.wien.gv.at/basemap/bmaporthofoto30cm/normal/google3857/{z}/{y}/{x}.jpeg

2015-09-27 21:39 GMT+02:00 Simon Legner :
> Hallo,
>
> es ist wieder soweit: Der Aufruf des geoimage.at-WMS liefert »Reached
> counter limit«.
>
> _al, kannst du bitte dein E-Mail vom 2012-07-10 ausgraben und eine
> Freischaltung erreichen?
>
> Danke und Grüße
> Simon
>
> ___
> Talk-at mailing list
> Talk-at@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-at

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

Re: [Talk-it] Violazione della Licenza di OpenStreetMap nel flyer di “DonomitiTour” di ADMO

[Martin Raifer]

> utilizzo della cartografia digitale OpenStreetMap

Ma perché pensi che si tratta di una mappa basata su dati di
OpenStreetMap? Non vedo una grande similarità comparando le due mappe
(per essempio usando [4]).

[4] http://bl.ocks.org/tyrasd/raw/42836f82b80a32089be2/


2015-09-10 13:31 GMT+02:00 Matteo Quatrida :
> Buongiorno,
>
> segnalo che ho ricevuto da un socio ADMO l'invito tramite flyer
> all'iniziativa “Donomiti Tour 2015” [1] e che ho prontamente risposto
> segnalando l'utilizzo della cartografia digitale OpenStreetMap senza
> rispetto della Licenza [2].
>
> Credo sia necessario inoltrare la stessa richiesta direttamente alla sede
> ADMO dell'Alto Adige [3], in modo che qualora non avessero già provveduto a
> stamparli, possano apportare la modifica.
>
> Cordiali saluti.
>
> [1]: http://it.tinypic.com/r/29vmb1v/8
> [2]: http://www.openstreetmap.org/#map=15/46.5371/11.4202=C
> [3]: http://www.admobz.com/
>
> --
> Matteo Quatrida
>
> “If a cluttered desk is a sign of a cluttered mind, of what, then, is an
> empty desk a sign?” --- Albert Einstein
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>

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

Re: [Talk-it] Editor ID e ortofoto PCN

[Martin Raifer]

 PCN non consente l'impiego di un proxy che crea tiles e li distribuisce

Whoots [1] potrebbe essere una soluzione: (è un tipo di proxy, ma non
distribuisce dei tile)


http://whoots.mapwarper.net:80/tms/{z}/{x}/{y}/OI.ORTOIMMAGINI.2006.32,OI.ORTOIMMAGINI.2006.33/http://wms.pcn.minambiente.it/ogc?map=/ms_ogc/WMS_v1.3/raster/ortofoto_colore_06.map

[1] http://whoots.mapwarper.net/

2015-07-21 9:09 GMT+02:00 Martin Koppenhoefer dieterdre...@gmail.com:


 sent from a phone

 Am 21.07.2015 um 08:59 schrieb Volker Schmidt vosc...@gmail.com:

 Probabilmente discusso qua già mille volte: le ortofoto PCN si possono
 utilizzare, al  livello tecnico, con ID?




 no, iD non legge WMS e PCN non consente l'impiego di un proxy che crea tiles
 e li distribuisce (credo, l'aveva fatto Luca D. e lo hanno imbruttito).

 ciao
 Martin

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


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

Re: [Talk-de] Tag für Fahrradzählstellen

[Martin Raifer]

Hallo!

Ich habe dafür schon die Tags man_made=monitoring mit
monitoring:bicycle=yes [1] im Einsatz gesehen. Z.B. hier:
http://www.openstreetmap.org/node/3400807630

[1] http://taginfo.osm.org/keys/monitoring%3Abicycle#map

Grüße, Martin

2015-05-30 11:40 GMT+02:00 Frau Klemm kwo...@outlook.com:
 Hallo Zusammen,



 ich wollte fragen, ob ein Tag für Fahrrad-Zählstellen gibt? Ich bin heute
 mit dem Rad in Berlin unterwegs gewesen und hab einige Zählstellen gefunden,
 die auf dem Radweg eingelassen wurden.



 Siehe link:



 https://www.dropbox.com/s/ifuzc8yd2a5ki5f/IMG_20150530_093503.jpg?dl=0



 http://www.rbb-online.de/panorama/beitrag/2015/03/berliner-radfahrer-werden-
 kuenftig-elektronisch-erfasst.html



 Könnt Ihr mir da weiterhelfen?



 Viele Grüße

 Robert

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

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

Re: [Talk-at] Details zu Modified Nodes herausfinden

[Martin Raifer]

Ein Großteil dieser Modifikationen dürfte in folgendem Changeset
passiert sein: http://www.openstreetmap.org/changeset/30778709

2015-05-05 11:02 GMT+02:00 Florian Michaeler flor...@michaeler.at:
 Hallo,

 ich war heute eher zufällig auf der OSMstats Seite (
 http://osmstats.neis-one.org/?item=countriescountry=Austria# ), dabei ist
 mir aufgefallen, dass am 04.05. in Österreich 34539 Nodes geändert wurden.
 Da ich ja prinzipiell neugierig bin und die Anzahl so weit über den
 üblichen 5000 - 6000 Änderungen pro Tag ist.
 Stellt sich mir die Frage, wie man hierzu nähere Details herausfinden
 könnte?

 lg
 Florian
 aka Miflo

 ---
 Diese E-Mail ist frei von Viren und Malware, denn der avast! Antivirus
 Schutz ist aktiv.
 http://www.avast.com


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

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

Re: [Talk-de] Fußgänger-Diskriminierung?

[Martin Raifer]

 Kurze Nachfrage. In wie fern hängen footway/path=sidewalk und 
 sidewalk=detached zusammen, bzw unterschieden die sich?

Diese Frage möchte ich wiederholen. Laut wiki [1] geht aus
footway=sidewalk doch recht eindeutig hervor, dass es sich bei einem
betreffenden Objekt mit dem Tag nicht um einen eigenständigen Weg
handelt, sondern eben um einen zu einer Straße zugehörigen Gehsteig.
Der Tag scheint auch schon häufig in Verwendung zu sein: [2].

Kann es sein, dass wir hier über ein Problem reden, das schon längst
gelöst ist? I.e. ein Router kann bei Vorhandensein von
footway=sidewalk den Namen der nächstgelegenen Straße holen bzw.
Renderer können einen vorhandenen Namen bei footway=sidewalk
weglassen, sofern es in der Nähe gleich benamte Straßen gibt, gleiches
gilt für Geocoder. Der Mapper hat dabei die Freiheit den Straßennamen
auch auf den Gehsteig zu taggen oder nicht. Und auch der Fall, dass
ein spezieller Gehsteig einen eigenen Namen hat (so Dinge wie [3]
z.B.) ist damit gut abgedeckt.

Grüße
Martin

[1] http://wiki.openstreetmap.org/wiki/DE%3ATag%3Afootway%3Dsidewalk
[2] http://taginfo.osm.org/tags/footway=sidewalk#overview
[3] http://www.openstreetmap.org/way/175773704

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

Re: [Talk-at] (no subject)

[Martin Raifer]

Falls noch jemand Schwierigkeiten mit dem File hat: Ich habe es
schlussendlich hinbekommen, indem ich im GeoTIFF manuell die
Lambert-Projektion (EPSG:31287) eingestellt habe. Das geht z.B. mit
folgendem gdal_translate Befehl:

  gdal_translate -a_srs EPSG:31287 -co TILED=YES -co
BLOCKXSIZE=128 -co BLOCKYSIZE=128 -co COMPRESS=LZW
dhm_lamb_10m.tif dhm_lamb_10m.fixed.tif

Grüße
Martin

2015-03-19 10:18 GMT+01:00 Martin Raifer tyr@gmail.com:
 z.B. liefert gdallocationinfo dhm_lamb_10m.tif -valonly -wgs84
 15.43753 47.07655
 bei mir eine Höhe von 366m, sie sollte aber eigentlich bei 475 liegen
 (Grazer Schloßberg). Der selbe Befehl mit den Koordinaten 15.43344
 47.07655 (eigentlich mitten in der Mur) liefert dann die gesuchten
 470m.

 Martin

 2015-03-18 19:56 GMT+01:00 Martin Raifer tyr@gmail.com:
 Version 2.8.1. Als verwendete Projektion wird bei mir folgendes
 angezeigt: Generated CRS (+proj=lcc +lat_1=46 +lat_2=49 +lat_0=47.5
 +lon_0=13.33 +x_0=40 +y_0=40 +datum=hermannskogel
 +units=m +no_defs). Abweichungen stelle ich auch fest, wenn ich mit
 gdallocationinfo (v1.11.0) Höhen auf dem File abfrage.

 2015-03-18 19:30 GMT+01:00 Werner Macho werner.ma...@gmail.com:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Hi!

 Welche QGIS Version? Ich hab hier die aktuelle Entwicklerversion und
 entdecke keinen Versatz.

 Grüße
 Werner

 On 03/18/2015 06:51 PM, Martin Raifer wrote:
 10x10m Geländemodell

 wow, das ist nicht schlecht! Allerdings: Wenn ich das tif-File in
 QGIS öffne, sehe ich einen (horizontalen) Offset von ca. 30-50m
 zwischen Höhenmodell und anderen Vergleichsdaten. Mache ich etwas
 falsch? Benutzt QGIS eine inkorrekte Projektion?

 Martin

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

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.15 (GNU/Linux)

 iEUEARECAAYFAlUJxC0ACgkQDAH1YiCxBgk8eACfeRBBtTLXLJvQxmJhWudw8GPO
 PHwAmKPtLIfyckPFCVd9Z2fRtb6pHIY=
 =RiLC
 -END PGP SIGNATURE-

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

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

Re: [Talk-at] (no subject)

[Martin Raifer]

z.B. liefert gdallocationinfo dhm_lamb_10m.tif -valonly -wgs84
15.43753 47.07655
bei mir eine Höhe von 366m, sie sollte aber eigentlich bei 475 liegen
(Grazer Schloßberg). Der selbe Befehl mit den Koordinaten 15.43344
47.07655 (eigentlich mitten in der Mur) liefert dann die gesuchten
470m.

Martin

2015-03-18 19:56 GMT+01:00 Martin Raifer tyr@gmail.com:
 Version 2.8.1. Als verwendete Projektion wird bei mir folgendes
 angezeigt: Generated CRS (+proj=lcc +lat_1=46 +lat_2=49 +lat_0=47.5
 +lon_0=13.33 +x_0=40 +y_0=40 +datum=hermannskogel
 +units=m +no_defs). Abweichungen stelle ich auch fest, wenn ich mit
 gdallocationinfo (v1.11.0) Höhen auf dem File abfrage.

 2015-03-18 19:30 GMT+01:00 Werner Macho werner.ma...@gmail.com:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Hi!

 Welche QGIS Version? Ich hab hier die aktuelle Entwicklerversion und
 entdecke keinen Versatz.

 Grüße
 Werner

 On 03/18/2015 06:51 PM, Martin Raifer wrote:
 10x10m Geländemodell

 wow, das ist nicht schlecht! Allerdings: Wenn ich das tif-File in
 QGIS öffne, sehe ich einen (horizontalen) Offset von ca. 30-50m
 zwischen Höhenmodell und anderen Vergleichsdaten. Mache ich etwas
 falsch? Benutzt QGIS eine inkorrekte Projektion?

 Martin

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

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.15 (GNU/Linux)

 iEUEARECAAYFAlUJxC0ACgkQDAH1YiCxBgk8eACfeRBBtTLXLJvQxmJhWudw8GPO
 PHwAmKPtLIfyckPFCVd9Z2fRtb6pHIY=
 =RiLC
 -END PGP SIGNATURE-

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

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

Re: [Talk-at] (no subject)

[Martin Raifer]

 10x10m Geländemodell

wow, das ist nicht schlecht!
Allerdings: Wenn ich das tif-File in QGIS öffne, sehe ich einen
(horizontalen) Offset von ca. 30-50m zwischen Höhenmodell und anderen
Vergleichsdaten. Mache ich etwas falsch? Benutzt QGIS eine inkorrekte
Projektion?

Martin

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

Re: [Talk-at] (no subject)

[Martin Raifer]

Version 2.8.1. Als verwendete Projektion wird bei mir folgendes
angezeigt: Generated CRS (+proj=lcc +lat_1=46 +lat_2=49 +lat_0=47.5
+lon_0=13.33 +x_0=40 +y_0=40 +datum=hermannskogel
+units=m +no_defs). Abweichungen stelle ich auch fest, wenn ich mit
gdallocationinfo (v1.11.0) Höhen auf dem File abfrage.

2015-03-18 19:30 GMT+01:00 Werner Macho werner.ma...@gmail.com:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Hi!

 Welche QGIS Version? Ich hab hier die aktuelle Entwicklerversion und
 entdecke keinen Versatz.

 Grüße
 Werner

 On 03/18/2015 06:51 PM, Martin Raifer wrote:
 10x10m Geländemodell

 wow, das ist nicht schlecht! Allerdings: Wenn ich das tif-File in
 QGIS öffne, sehe ich einen (horizontalen) Offset von ca. 30-50m
 zwischen Höhenmodell und anderen Vergleichsdaten. Mache ich etwas
 falsch? Benutzt QGIS eine inkorrekte Projektion?

 Martin

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

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.15 (GNU/Linux)

 iEUEARECAAYFAlUJxC0ACgkQDAH1YiCxBgk8eACfeRBBtTLXLJvQxmJhWudw8GPO
 PHwAmKPtLIfyckPFCVd9Z2fRtb6pHIY=
 =RiLC
 -END PGP SIGNATURE-

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

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

Re: [Talk-at] OGD Vienna Tree update (?)

[Martin Raifer]

Nein, es wurden definitiv schon Bäume aus dem Import gelöscht, z.B.
node 2043852983 [0]. Die Zahl der in der Zwischenzeit gelöschten
importierten Bäume dürfte in etwa bei 700 liegen. Herausgefunden habe
ich das über eine augmented diff[1] Abfrage auf die Overpass API, die
den Zustand der OSM zwischen dem 3.12.2012 (also kurz nach dem Import)
und heute ausgibt [2] (test-query, siehe Daten-Tab), [3] (alle
Änderungen für ganz Wien).

Beachtest du vielleicht nicht, dass gelöschte (visible=false) Elemente
keine Tags mehr besitzen, welche also von der Vorgängerversion des
selben Objekts geholt werden müssen? Ansonsten kann ich mir dein
Problem nicht wirklich erklären.

Martin

[0] http://www.openstreetmap.org/node/2043852983/history
[1] 
http://wiki.openstreetmap.org/wiki/Overpass_API/Overpass_QL#Augmented_Delta_between_two_dates_.28.22adiff.22.29
[2] http://overpass-turbo.eu/s/8bX
[3] 
http://overpass-api.de/api/interpreter?data=%5Bout%3Axml%5D%5Btimeout%3A225%5D%5Badiff%3A%222012-12-03T00%3A00%3A00Z%22%5D%3B%0Aarea%283600109166%29-%3E.searchArea%3B%0A%28%0A%20%20node%5B%22natural%22%3D%22tree%22%5D%5B%22source%22%3D%22OGD%20Vienna%22%5D%0A%20%20%28area.searchArea%29%0A%20%20%2F%2F%2848.27334658037655%2C16.332828998565674%2C48.27670982090194%2C16.340076327323914%29%0A%20%20%3B%0A%29%3B%0Aout%20meta%3B


2015-03-14 22:04 GMT+01:00 Markus Mayr markus4mayr.li...@gmail.com:
 Hallo, Liste!

 Ich tüftle gerade an einem Aktualisierungsprozess für den Wiener OGD
 Baumkataster. Dabei möchte ich mithilfe des Full-History-Dumps jene
 Bäume erkennen, die zwar ursprünglich importiert, aber von der OSM
 Community gelöscht wurden.
 Bei der Aufbereitung des History-Dumps für Wien bin ich mir nicht
 sicher, ob ich das richtige Ergebnis erhalten habe.
 Durch den Vermerk visible=true/false wird in einem History-Dump
 gekennzeichnet, ob das jeweilige Objekt noch sichtbar ist, oder nicht.
 In meinem Ausschnitt von Wien finde ich für Bäume aber ausschließlich
 true. Weiß jemand von einer bestätigten Löschung eines Baumes in Wien
 nach dem Import? Ich kann mir nicht vorstellen, dass es nie eine
 Löschung gegeben hat?

 lg, Markus

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

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

Re: [OSM-talk] Accessing center feature from Overpass XML?

[Martin Raifer]

The syntax looks like the following in Overpass-XML:

print mode=meta geometry=center/

For the geometry parameter one has the options center, bounds,
full and skeleton (=regular osm xml without added geometry data).
If you are only interested in center coordinates for some objects, you
probably want to drop the two lines after your first print statement
(the recurse and additional print are normally there to grab the
object's geometry).

On Thu, Oct 9, 2014 at 11:55 PM, Bryce Nesbitt bry...@obviously.com wrote:
 I know how to use out meta center; in Overpass query language to get
 the center of a way.

 What's the equivalent in Overpass XML?  I tried adding it to the
 print, but I can't find documentation on print and the command is
 rejected:

 osm-script output=xml timeout=25
   union
 query type=node
   has-kv k=amenity v=toilets/
   bbox-query {{bbox}}/
 /query
 query type=way
   has-kv k=amenity v=toilets/
   bbox-query {{bbox}}/
 /query
   /union
   print mode=meta center/
   recurse type=down/
   print mode=meta center order=quadtile/
 /osm-script

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

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

Re: [Talk-at] Fehlerhafte Turning restrictions in Wien

[Martin Raifer]

 Genau darum geht's mir gerade. Gibt's da irgendeine Möglichkeit false
 positives auszumisten und/oder fehlerhafte Regeln zu beanstanden? Ich
 hab da jetzt auf die schnell nichts gefunden.

Ich würde mich entweder direkt bei User Zartbitter melden:
http://www.openstreetmap.org/user/Zartbitter und/oder im Forum-Thread
antworten, wo er ursprünglich die Auswertung vorgestellt hat:
http://forum.openstreetmap.org/viewtopic.php?id=19834

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

Re: [Talk-at] Revert - Connect timed out

[Martin Raifer]

 Ich hätte gerne gewusst, was User Petr Slavíček geändert hat:
 Er schreibt: simplify wood Dachstein
 Ich gehe davon aus, dass er die Latschenflächen bereinigt, indem er
 massenhaft Punkte gelöscht hat.

Ja, das scheint wirklich so zu sein. So hat es vorher ausgesehen:
http://overpass-turbo.eu/s/3H1

Zugegebenermaßen sind die Flächen wirklich schon sehr detailiert
gemappt, und hier und da scheint auch mal ein größerer Stein als
Latsche gurchgegangen zu sein
(https://www.openstreetmap.org/way/139254114). Außerdem werden
Latschen doch als scrub und nicht als wood getaggt, nicht?

Natürlich wäre das trotzdem für kein Grund dafür die Polygone so
extrem zu vereinfachen, u.A. mit dem Ergebniss von sich selbst
überschneidenden Geometrien. :(

 Ich hätte das nun wieder gerne zurückgesetzt.
 Versucht habe ich es mit JOSM 7000, und dem Tool Änderungssatz umkehren

Bei mir ist ein revert durchgegangen (nach sehr langer
Bearbeitungszeit; mit JOSM 7182) - oder meinst du, dass bei dir das
Hochladen nicht funktioniert hat?

Martin

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

Re: [Talk-at] JOSM: Gebäude ausschalten

[Martin Raifer]

Ich glaube die Filter Funktion ist das richtige für dich:
https://josm.openstreetmap.de/wiki/Help/Dialog/Filter

Grüße
Martin

2014-05-16 9:43 GMT+02:00 Christian Aigner caig...@openstreetmap.at:
 Am 16.05.2014 09:29, schrieb Christian Aigner:
 Ich möchte im Moment nur Buslinien editieren. Dazu müssen nur die
 Straßen, Haltestellen und Plattformen sichtbar sein.

 Wie kann ich alles andere ausschalten (unsichtbar machen)?

 LG,
 Christian


 Ich hab den MapPaint-Style geändert, aber die Gebäude werden immer noch
 grau angezeigt. Kann man das auch noch ausschalten?

 LG,
 Christian


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

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

Re: [Talk-de] Gelöschte Daten finden [was: 3D-Mapping]

[Martin Raifer]

http://overpass-turbo.eu/s/3hP

2014-05-07 20:13 GMT+02:00 Markus liste12a4...@gmx.de:
 Hallo Andreas,

 Kann man gelöschte Dinge eigentlich irgendwie suchen und wieder finden?
 Beispielsweise mit einer Boundingbox?
 Wie?


 Im Moment kannst du auch einfach noch den Mapstyle ändern.


 Gesehen habe ich das Kunstwerk schon.
 Ich möchte mir gern die Daten anschauen.

 Auch in anderen Zusammenhängen suche ich immer mal wieder gelöschte Daten.
 Aber weiss nicht wie das geht...

 Gruss, Markus


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

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

Re: [Talk-de] Gelöschte Daten finden [was: 3D-Mapping]

[Martin Raifer]

(Sorry, die letzte E-Mail ging etwas zu früh raus.)

Was ich sagen wollte ist, dass die Overpass-API seit Kurzem es auch
ermöglicht, Daten aus der Vergangenheit (von OSM) zu holen. Dazu z.B.
einfach im Parameter date des osm-script-Tags das gewünschte
Datum angeben. In dem oben gesenden Link verwende ich das, um die
gelöschten 3D-Gebäude¹ anzuzeigen.

Grüße
Martin

[1] https://gist.github.com/tyrasd/a16e47d5fcd928e6e4d0

2014-05-07 22:19 GMT+02:00 Martin Raifer tyr@gmail.com:
 http://overpass-turbo.eu/s/3hP

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

Re: [Talk-at] OGD Shapefile - GPX via JOSM und osmconvert

[Martin Raifer]

Mit QGIS (o.Ä.) die Polygone in Punkte umwandeln
(Vektor-Geometrie-Werkzeuge-Polygonschwerpunkt), dann erst in JOSM
öffnen, …

https://gist.github.com/tyrasd/137d1f4f93fbf0330197

(Konvertiert habe ich das mittels osmtogeojson [1] und togpx [2]:
`osmtogeojson naturdenkmale.osm | togpx  naturdenkmale.gpx`, weil
JOSM anscheinend nur tracks und keine waypoints exportiert‽ – gpsbabel
u.Ä. sollten aber auch klappen.)

Martin

[1] https://www.npmjs.org/package/osmtogeojson
[2] https://www.npmjs.org/package/togpx

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

Re: [Talk-at] Vorarlberg: Radwege vom Land erhalten!

[Martin Raifer]

2014-04-24 11:56 GMT+02:00 Andreas Labres l...@lab.at:
 Ich weiß ja nicht, wie ihr das im Detail macht, aber irgendwie klingt mir das
 nicht nach Import, sondern nach viel Handarbeit mit halt einer speziellen
 Vorlage.

Würde ich auch so sehen, aber das heißt ja nicht, dass man solche
Mapping-Projekte nicht trotzdem vorher gut planen, koordinieren,
dokumentieren, usw. sollte. ;)

 On 23.04.14 22:15, Michael Maier wrote:
 Bei Beginn des Projektes waren nur 4 Routen-Relationen in der OSM vorhanden

Wie kommst du auf 4 Routen in OSM? Ich zähle aktuell 14 Stück:
http://overpass-turbo.eu/s/39J ;)

Habt ihr euch schon überlegt, was ihr macht, wenn sich die Daten vom
VoGIS nicht mit den bereits bestehenden OSM-Routen decken? Z.B.
Routenverlauf des Bodensee-Radwegs ganz östlich von Bregenz, konkrete
Schreibschweisen von Namen (Bodensee Radroute oder
Bodenseeradweg)…

Ich bin mir nicht sicher, ob die Radweg-Nummern auch in der Praxis
verwendet werden. Die Beschilderungen scheinen zumindest ohne Nummern
auszukommen, und google spuckt bei der Suche nach den entsprechenden
R-Nummern auch nichts aus. Hm… Besser nur als ref:vogis=Rxxx taggen?

Grüße
Martin

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

Re: [Talk-at] Über Imports

[Martin Raifer]

Als Hintergrund wie ich dazu gekommen bin den Artikel zu verfassen:
Möglicher Gebäude-Import in Südtirol:
https://lists.openstreetmap.org/pipermail/talk-it-southtyrol/2014-April/000129.html

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

Re: [Talk-de] OSM-Layout. Visualisierungs-Fehler in der Kartendaten-Analyse

[Martin Raifer]

[Demo: http://overpass2.apis.dev.openstreetmap.org/]


[…] Die Relation mit der Nummer 302588 konnte leider nicht gefunden  
werden.


Das liegt lediglich an technischen Beschränkungen des Entwicklungs-Server,  
wo die Demo aktuell installiert ist. In der endgültigen Version würde das  
natürlich auf die entsprechende Seite (hier also  
http://osm.org/relation/302588) weiterleiten.


Grüße
Martin

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

Re: [Talk-de] OSM-Layout. Visualisierungs-Fehler in der Kartendaten-Analyse

[Martin Raifer]

Zur Zeit wird einem verbesserten Daten-Analyse-Werkzeug gearbeitet, das
möglicherweise in Kürze den Daten-Layer ersetzen wird:

Demo: http://overpass2.apis.dev.openstreetmap.org/
Diskussion  Code:
https://github.com/openstreetmap/openstreetmap-website/pull/721

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

Re: [OSM-talk] Should we map former endonyms?

[Martin Raifer]

I would say that it depends:

* If the name is still regularly used to name a place (for example in  
newspapers, etc.), use name:*

* If the name has become out-of-use, use old_name:*
* If the name is still used by locals, use loc_name:* or reg_name:*

A somewhat similar situation than what you described can be found in  
Trentino in Northern Italy which used to be part of the Austro-Hungarian  
Empire until WW1. Before that, places had bilingual names in both Italian  
and German – nowadays the German names have largely become out of use. But  
there are some exceptions like the capital, some valleys and mountain  
ranges, …. Also, some German-speaking people from towns near to the border  
are still calling nearby towns of Trentino by their former names.



The question is, does a name disappear when it is no longer used?


I would say that a name almost never disappears. Instead, only its  
qualification can change: from commonly-used/official to a (local) exonym  
to a historic name (… maybe even to a point where it is almost completely  
forgotten).



My 2 cents from somebody who just happens to live in a region with some  
quite interesting place-naming situations ;)

Martin

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

Re: [Talk-de] Notes-RSS-Feed

[Martin Raifer]

Am 15.03.2014, 18:20 Uhr, schrieb Andreas Neumann andr-neum...@gmx.net:


Oder gibt es einen RSS-Feed für Notes in einem Gebiet, der dieses
Feature bietet?


Wenn ich dich richtig verstehe suchst du das hier:

  
http://www.openstreetmap.org/api/0.6/notes/feed?bbox=10.824,50.636,10.968,50.75

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

Re: [OSM-talk] OpenStreetMap Isn't All That Open, Let's Change That and Drop Share-Alike

[Martin Raifer]

To throw another log into the fire: What about imports?

OSM having a share-alike licence enabled us to incorporate (and otherwise  
use) all kinds of open data sets, which may be licensed PD/CC0, CC-BY,  
CC-BY-SA or ODbL. (A lot of open government data in the EU is released  
under CC-BY or even share-alike.)


If OSM would switch to something more liberal, we would cut us off from  
potential source material: If we were going to CC-BY our database, we  
couldn't use CC-BY-SA and ODbL material any more, and if we were going all  
the way to CC0, anything other than PD/CC0 would be a no-go.


Martin

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

Re: [Talk-it-southtyrol] New fix for the Import of house number Southtyrol

[Martin Raifer]

you can find the new osm files to download.


Awesome. Thanks for your efforts and the much improved files.


 * Fixed the ß problems of the german street names


It looks like the strasse-straße substitution didn't work. (To be clear:  
it should be Weinstraße not Weinstrasse, for example – sorry if there  
was some confusion in my last mail.)


Please check the new files. If they are acceptable we will proceed with  
the import


Only one more thing: The special rules for ladin towns [1].
* place names should be shortened if the name is the same in two languages:
  - Badia - Badia - Abtei - Badia - Abtei
  - Corvara - Corvara in Badia - Corvara - Corvara - Corvara in Badia
* for all other names (addr:hamlet, addr:place, addr:street) the Ladin  
names (e.g. addr:street:lld) are missing.
* I think we initially said that: “The street names in Ladin towns are  
only signposted in Ladin, therefore […] the tag  addr:street should be the  
same as addr:street:lld”[1]. (I'd add that this should also apply to  
addr:place as well.)


Then I think we should finally be ready to go! :)

Martin

[1]  
https://wiki.openstreetmap.org/wiki/AltoAdige_-_Südtirol/OpenGisData_HouseNumber_Import2#Ladins_towns


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

Re: [Talk-at] Mappen von Gehsteigen

[Martin Raifer]

Am 27.02.2014, 14:47 Uhr, schrieb Kevin Kofler kevin.kof...@chello.at:


aufzuräumen: http://www.openstreetmap.org/changeset/20809099


Ich empfinde die Situation jetzt deutlich schlechter als vorher. Ich habe  
mir jetzt schnell die Situation am Urban-Loritz-Platz angeschaut, und nach  
deinem Aufräumen finde ich auf die Schnelle folgende Probleme, die  
vorher nicht vorhanden waren:


http://666kb.com/i/cm7jwktlnv7yn2lhb.jpg

(1) Fußweg endet im Vakuum?
(2) Fußweg endet am Tram-Gleis?
(3),(4) Fußweg quer über geparkte Autos?
(5),(6) Keine Verbindungen vom Platz zum Geh-/Radweg auf der  
gegenüberliegenden Straßenseite?


Dass vorher die footway=sidewalk bzw. footway=crossing Attribute gefehlt  
haben stimmt, aber das hätte man doch einfach korrigieren können, ohne  
blinde Löschwut. :( Dein Vorgehen würde auf Gebäude umgelegt in etwa  
bedeuten, alle jene Häuser zu löschen, wo noch keine Adressen gesetzt sind.


Hast du dich überhaupt zumindest vorher mit dem Mapper, der die Gehsteige  
gemappt hat unterhalten (User Railjet – er scheint ziemlich erfahren zu  
sein)? Entschuldige wenn ich das so direkt sage, aber dein Verhalten  
erscheint mir ziemlich respektlos.


Grüße
Martin

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

Re: [Talk-at] Mappen von Gehsteigen

[Martin Raifer]

Am 27.02.2014, 19:36 Uhr, schrieb Stefan Tauner stefan.tau...@gmx.at:


http://666kb.com/i/cm7jwktlnv7yn2lhb.jpg

(3),(4) Fußweg quer über geparkte Autos?


Bei 3 und 4 werden Anti-Gehsteig-Mapper kein Problem sehen (und ich auch  
nicht: Überquerung der Straße ist überall möglich und gleichzeitig dient  
die Straße ja dazu den Gehsteig abzubilden).


Eine Querung ist zwar möglich, aber nur für Leute ohne Rollstuhl,  
Kinderwagen, o.Ä. – das müsste entsprechend getaggt werden. Außerdem: wäre  
das Queren hier überhaupt erlaubt? Da ist ja nur 15m weiter ein  
Ampel-geregelter Zebrastreifen… Wenn nein, dann müsste dort sogar noch  
eine Abbiegebeschränkung (no_straight_on) hin.


Martin

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

Re: [Talk-at] Mappen von Gehsteigen

[Martin Raifer]

Am 27.02.2014, 20:14 Uhr, schrieb Kevin Kofler kevin.kof...@chello.at:


Unlängst hat Wiens Fußgängerbeauftragte Petra Jens in einer TV-Diskussion
ausdrücklich betont, daß die Straße eben NICHT nur die Fahrbahn ist (das  
ist eine sehr autozentrische Sicht), sondern der Gehsteig genauso zur

Straße gehört. Wenn wir die Gehsteige aber jetzt alle extra mappen, dann
pflegen wir genau diesen autozentrischen Straße=Fahrbahn Irrtum.


Das stimmt zwar, aber streng genommen mappen wir in OSM als beispielsweise  
highway=teriary keine Straße, sondern eben genau eine Fahrbahn! Das wird  
deutlich, wenn man bedenkt, wo wir die highway-Wege in die einzelnen  
Richtungen aufsplitten: Immer genau dort, wo eine Straße mehrere  
(Richtungs-)Fahrbahnen hat.
Und genau hier führt dein Argument ins Leere: Denn der Gehsteig ist eben  
_kein_ Bestandteil der Fahrbahn, sondern von dieser getrennt. Trotzdem  
möchtest du in OSM einen Gehsteig dann per Zusatz-Tags quasi als Anhängsel  
der Fahrbahn betrachten. Komisch.


Martinn

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

Re: [Talk-at] Mappen von Gehsteigen

[Martin Raifer]

Am 27.02.2014, 20:39 Uhr, schrieb Kevin Kofler kevin.kof...@chello.at:


Martin Raifer wrote:

[in OSM werden Fahrbahnen gemappt]


Das tun wir eben nicht, sonst würde in der Stadt jede einzelne
Zweirichtungsstraße doppelt gemappt sein […], das
ist aber nicht der Fall. Selbst die Überlandstraßen (sind meistens nicht
doppelt gemappt. Und meiner Meinung nach ist das auch gut so! Getrenntes
Mapping der Richtungsfahrbahnen ist wirklich nur dort sinnvoll, wo es  
eine bauliche Trennung gibt, z.B. bei Autobahnen. Genau dasselbe gilt

auch für die Gehsteige.


Ich glaube du verwechselst schlicht den Begriff Fahrbahn mit  
Fahrspur/Fahrstreifen [1]. Mehrere Fahrbahnen sind per Definition baulich  
voneinander getrennt! ;)



(z.B. Lerchenfelder Straße)


So weit ich es am Luftbild beurteilen kann, sieht diese Straße nach einer  
gewöhnlichen Straße mit nur einer Fahrbahn [1] aus. Außer im Bereich der  
Kreuzung zur Auerspergstraße [2], aber dort sind in OSM eh zwei Fahrbahnen  
gemappt.


Grüße
Martin

[1] http://de.wikipedia.org/wiki/Straßenquerschnitt#Fahrbahn
[2] http://www.openstreetmap.org/#map=19/48.20681/16.35520

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

Re: [Talk-at] Mappen von Gehsteigen

[Martin Raifer]

Am 26.02.2014, 11:45 Uhr, schrieb Michael Maier:


Genau deswegen halte ich sidewalk=* für komplizierte Situation für
furchtbar verrückt, Beispiel (Linkskurve): […]



Was bei deinem Beispiel noch gar nicht vorkommt, aber die praktische
Umsetzung des Gehsteig-als-Tags-Mappings noch einmal deutlich
verkompliziert, ist, dass an jeder Stelle wo sich die Eingenschaft auch
nur eines der beteiligten Verkehrswege ändert (z.B. Breite oder
Beschaffenheit des Gehsteigs, Anzahl der Spuren der Straße) das
Gesamtgebilde aufgetrennt werden muss.

Nehmen wir als Beispiel folgendes Stück der Leonhardstraße in Graz:
http://www.openstreetmap.org/way/110460282 (ca. 250m) - Der südliche
Gehsteig hat in etwa auf Höhe der Metzgerei eine kurze Stiege (mit Rampe,
aber viel zu Steil für Rollstuhlfahrer), danach folgt ein kleiner Platz
mit mehreren Hindernissen (Mistkübel, Fahrradparkplatz), dann folgt ein
Stück mit (wegen Parkbuchten und Gastgärten) variierender (ca. 5-6 mal)
Breite. Ähnliche Situation am nördlichen Gehsteig.

Diese Straße müsste praktisch in 15-20 Stücke zerteilt werden, um alle
sidewalk:right/left:* Eigenschaften korrekt zu platzieren. Viel Spaß
damit, und beim weiteren Bearbeiten der Straße oder der Gehsteige.

Bei getrenntem Gehsteig-als-Way-Mapping ist immer nur derjenige
Verkehrsweg genau dort aufgetrennt, wo sich jeweils etwas ändert. Easy. :)


Martin

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

Re: [Talk-at] Mappen von Gehsteigen

[Martin Raifer]

Ich war anfangs auch kein Freund des Gehsteig-Mappings. Mittlerweile finde  
ich aber, dass das sehr wohl sinnvoll sein kann, und zwar aus folgenden  
Gründen:


1. Es ist einfach intuitiver jeden getrennten Verkehrsweg extra zu mappen:  
Es benötigt keine Einlese-Arbeit im Wiki (seinen wir mal ehrlich, kein  
Mensch liest sich das Wiki durch bevor man anfängt zu mappen). KISS [1]
2. Man erhält akkuratere Geometrien. Sehr viele Kreuzungen lassen sich mit  
den jeweiligen Fußgängerkreuzungsmöglichkeiten gar nicht anders erfassen.
3. Attribute der Straße treffen oft nicht auf die Gehsteige zu und  
umgekehrt (z.b. Oberfläche, Breite, Hindernisse, Stufen, etc.). Man  
_könnte_ vieles davon auch über komplexe Attribute abbilden, aber das  
erfordert wieder mehr Einarbeitung - siehe Punkt 1.
4. Wenn zwischen Straße und Gehsteig sich trennende Elemente (z.B. Bäume  
einer Allee, kleine Mauer, Randsteine, etc.) befinden können diese auch  
nicht topologisch korrekt platziert werden ohne separatem Gehsteig.


Für ein gescheites Rollstuhlfahrer-Routing benötigt man relativ  
detaillierte Daten über die Geometrie und Beschaffenheit der Gehsteige.  
Ich sehe dafür keine praktikable Alternative zum separaten  
Gehsteig-Mapping.


Natürlich ist in vielen Fällen das Mappen als Attribut der Straße im  
ersten Moment erstmal gut genug. Trotzdem finde ich nicht, dass man  
Leuten, die die Qualität der OSM-Daten verbessern wollen, das verbieten  
sollte.


Ich sehe auch nicht, was denn gegen das Gehsteig-Mapping spricht? Außer,  
dass man einen etwas längeren Verkehrswege-Graphen zu verwalten hat – aber  
das scheint bei allen anderen Arten von Micromapping (3D-Gebäude, einzelne  
Spielzeuge in Spielplätzen, …) ja kein Problem zu sein.


Schöne Grüße
Martin

[1] http://de.wikipedia.org/wiki/KISS-Prinzip

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

Re: [Talk-at] Mappen von Gehsteigen

[Martin Raifer]

Am 25.02.2014, 11:33 Uhr, schrieb Friedrich Volkmann b...@volki.at:

Mit den vielen komplexen Relationen haben wir uns längst von KISS  
verabschiedet.


Das finde ich nicht. Relationen werden aktuell eigentlich nur dort  
verwendet, wo es schlicht keine einfachere Alternative gibt (wie sollte  
man sonst Polygone mit Löchern, Abbiegebeschränkungen oder ÖPNV-Routen  
implementieren?). Außerdem kann im iD-Editor mit all diesen Relationen von  
puren Anfängern ganz ohne Einlesezeit gearbeitet werden: Bei einfachen  
Bearbeitungen (z.B. Way Splitten) bekommt der User gar nicht mit, dass  
eine Relation im Spiel ist, komplexere Bearbeitungen wie ein Gebäude mit  
Innenhof erstellen funktioniert kinderleicht über das + Werkzeug.


Editieren ist heute nichts mehr, was ohne Beschäftigung mit der  
Dokumentation geht.


Es geht doch eher darum, wieviel Einarbeitung notwendig sein soll. Ich  
finde: So wenig wie möglich. Meiner Meinung nach sollte das Walkthrough  
(z.B. beim ersten Start) von iD ausreichen.


2. Man erhält akkuratere Geometrien. Sehr viele Kreuzungen lassen sich  
mit den jeweiligen Fußgängerkreuzungsmöglichkeiten gar nicht anders  
erfassen.


Da kommst du aber vom Hundersten ins Tausendste, denn mit der selben  
Begründung könntest du auch die Fahrspuren einzeln mappen, die Radwege  
sowieso, samt Abbiegerelationen zu den Fahrspuren, und dann hast du noch  
das Problem, wo du die Ampeln setzt. Und hast du nicht etwas von KISS  
geschrieben?


OK, du hast vielleicht Recht. Man sollte nicht von Spezialfällen auf die  
Allgemeinheit schließen (kann man bei einer Kreuzung mit  
Fußgänger-Mittelinsel von einem Spezialfall sprechen? Hmmm…). Das schwächt  
mein Argument etwas ab, trotzdem bleibt der Wunsch nach einer in sich  
konsistenten Lösung.


3. Attribute der Straße treffen oft nicht auf die Gehsteige zu und  
umgekehrt (z.b. Oberfläche, Breite, Hindernisse, Stufen, etc.). Man
_könnte_ vieles davon auch über komplexe Attribute abbilden, aberdas  
erfordert wieder mehr Einarbeitung - siehe Punkt 1.


Wenn man sich nicht einarbeiten will, kann man diese Attribute für den  
Gehsteig auch ganz weglassen. Ob er 2m oder 3m breit ist, interessiert  
sowieso niemanden.


Wie bereits oben erwähnt geht es ja darum wie lange man sich einarbeiten  
muss. Wenn Gehsteige separat gemappt werden kann das was man bereits für  
die Attributierung von normalen Straßen gelernt hat direkt ohne Neu-Lernen  
auf die Gehsteige anwenden. Im anderen Fall muss man sich doppelt so  
lange einarbeiten.


Man sollte auch bedenken, dass ein Anfänger ja gar nicht wissen kann, dass  
Gehsteige unter Umständen anders zu behandeln sind als andere Gehwege.



4. Wenn zwischen Straße und Gehsteig sich trennende Elemente (z.B. Bäume
einer Allee, kleine Mauer, Randsteine, etc.) befinden können diese auch
nicht topologisch korrekt platziert werden ohne separatem Gehsteig.


Wenn Bäume oder eine Mauer dazwischen stehen, ist das eine bauliche  
Trennung und dann ist separates Mapping Konvention.


Ist der Bordstein denn keine bauliche Trennung? Oder anders gefragt: Wäre  
ein Bordstein zwischen den beiden Richtungsfahrbahnen, würde man diese  
doch auch getrennt mappen, oder?
Außerdem findet man in Städten sehr häufig Parkplätze zwischen Straße und  
Gehsteig, ist das bauliche Trennung genug?



Für ein gescheites Rollstuhlfahrer-Routing […]


Das Rollstuhlfahrerrouting geistert durch die Diskussionen wie der  
Fuchsbandwurm und die Spinne in der Yuccapalme, die noch nie ein Mensch  
real gesehen hat.


Ich kann dir versichern, dass es aktuell mehrere Projekte gibt, die sich  
intensiv mit Rohlstuhl-Routing in Zusammenhang mit OSM beschäftigen. Michi  
(species) kann dir dazu sicher mehr erzählen. Wie du weißt zeichnet sich  
OSM dadurch aus, dass wir der einzige Datenlieferant sind, bei dem  
Fußgänger wie Rollstuhlfahrer nicht gegenüber Autofahrern diskriminiert  
werden.


Martin

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

Re: [Talk-it-southtyrol] Talk-it-southtyrol Digest, Vol 12, Issue 9

[Martin Raifer]

Am 20.02.2014, 15:06 Uhr, schrieb tomas tra...@tomyt.net:

It's too hard for me to write in a mailing list, even more in english,  
it's not my Job. I give up. I'll probably unsubscribe.


Please don't do that. ;) If you are not comfortable with English, just  
write in Italian or German!


I personally began to write in English in the housenumbers import thread  
because I thought that it would make it easier for external people to  
follow the discussion.


I'm happy about the help kindly received on the discussion and happy  
about new and correct data in osm and I hope this can encourage some  
other people to map their town and other places.


+1 :)

I'm less happyer about my ignorance regarding mailings lists and about  
some bit aggressive answers that I received.


Please don't get too upset on this. Sometimes mailing lists can feel a  
little bit harsh, because it's not always easy to express an opinion both  
strongly to the point and politely. Also there is always much room for  
misinterpretations (especially in slightly political topics) that can make  
conversations even more slippery. I am also sometimes a little  
over-the-top ([1], [2]) maybe. Please excuse me and don't take it too  
personally. ;)


Happy mapping!
Martin


[1] http://lists.opengisdata.eu/pipermail/mappers/2014-February/59.html
[2] http://www.openstreetmap.org/note/120794

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

Re: [Talk-at] Adressen mit nur halboffiziellen Straßebezeichnungen

[Martin Raifer]

Am 12.02.2014, 19:09 Uhr, schrieb Christian xni...@gmail.com:

Hat irgendjemand einen Vorschlag, wie man beide Varianten auffindbar  
taggen kann?


Jeweils zwei Address-Nodes setzen (1x addr:street und 1x addr:place)? So  
ähnlich wie für Häuser, die an mehreren Straßen Hausnummern haben…


Martin

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

Re: [Talk-de] St.-ZickeZacke-Str.

[Martin Raifer]

Am 06.02.2014, 19:09 Uhr, schrieb Peter Wendorff  
wendo...@uni-paderborn.de:



Saint Paul’s Cathedral


Lustig, die Engländer haben anscheinend kein Problem mit dem St. in  
Eigennamen (und das trotz Verwechslungsgefahr Saint/Street):


http://www.openstreetmap.org/way/4959544#map=19/51.51372/-0.09845

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

Re: [Talk-de] St.-ZickeZacke-Str.

[Martin Raifer]

Ich möchte noch einmal die eigentlich schon in meinem Anfangsposting in  
den Raum gestellte These/Frage wiederholen:


Wieso schreiben wir in OSM Straßennamen nicht wie ihn praktisch Jeder in  
Texten schreiben würde? So, wie er in Tageszeitungen vorkommt, so wie er  
in Enzyklopädien vorkommt, so wie er in Broschüren vorkommt, so wie er auf  
offiziellem Briefpapier vorkommt, so wie er am Straßenschild stehen würde  
wenn dort nicht aus Platzgründen abgekürzt werden müsste, …?


Es ist meiner Meinung nach nicht sinnvoll Mappern irgendwelche von der  
Realität abweichende Regeln aufzudrücken, die weder intuitiv sind noch aus  
anderen Gründen gerechtfertigt. Vor allem nicht für so etwas alltägliches  
wie den Namen eines Dinges hinzuschreiben. KISS [2]


Es geht doch praktisch fast nur um zwei Fälle: St. und Dr.. Beides  
sind in gewisser Weise Titel von Personen, die im echten Leben fast immer  
abgekürzt werden. Verwechslungen können unter Berücksichtigung des  
Kontextes (Name eines Ortes oder Straße) ausgeschlossen werden. (z.B.:  
St. steht laut Duden [1] für Sankt, Stück oder Stunde. Letztere beiden  
können bei Straßen oder Orten nicht vorkommen.)


Liebe Grüße
Martin

[1] http://www.duden.de/rechtschreibung/St_
[2] https://de.wikipedia.org/wiki/KISS-Prinzip

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

Re: [Talk-de] St.-ZickeZacke-Str.

[Martin Raifer]

[fullquote]


bei Straßennamen kann alles vorkommen
http://www.openstreetmap.org/way/236770778


Ich sehe den Zusammenhang dieses Beispiels nicht? Niemand würde diese  
Straße als Im St. schreiben, oder?



Wie schon erwähnt und Dir als Südtiroler sicher klar, bei S. Anna und S.
Anton und S. Barbara und S. Bernardo und S. Stefano ist es halt nicht  
mehr klar. (Sant'Anna, Sant'Anton, Santa Barbara, San Bernardo, Santo  
Stefano).


Wir sprechen hier ja nur von deutschsprachigen Heiligen; in Südtirol also  
der Wert in name:de. Wenn irgendwo eine deutschsprachige Straße, Ort oder  
Platz nach einem fremdsprachigen Heiligen benannt wurde (hypothetisches  
Beispiel: Platz des San Bernardo), soll man diesen logischerweise  
ausschreiben, so wie man es (wie gesagt) in einem normalen Text  
(Zeitungsartikel, Buch, Lexikon) eben auch tun würde. Ganz natürlich ohne  
Zwang.


Grüße,
Martin

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

Re: [Talk-de] St.-ZickeZacke-Str.

[Martin Raifer]

Dass auf Schildern aus Platzgründen oft abgekürzt wird stimmt. Ich bin  
dafür den Namen so einzutragen, wie er vollständig vor Ort von der  
Bevölkerung wahrgenommen und verwendet wird.


Ich glaube on-the-ground ist nicht wort-wörtlich zu verstehen, denn das  
Schild ist eben nicht das einzige on-the-ground Medium, das den Namen  
einer Straße verwendet.


Natürlich sollen Vornamen oder andere nicht-übliche Abkürzungen die auf  
Straßennamensschildern abgekürzt stehen in OSM ausgeschrieben werden.  
Titel sowie der Namenszusatz St. von Personen jedoch nicht, weil es im  
echten Leben offensichtlich in den meisten Fällen nicht üblich [1] ist  
diese auszuschreiben.


Ich gehe davon aus, dass die allermeisten Mapper bereits instinktiv  
(“Hausverstand”) nach dieser Methode vorgehen. Nur sollte man das  
akzeptieren und die Situation nicht durch anderweitige Regeln  
verkomplizieren.


Liebe Grüße
Martin

[1] Hier einige Beispiele:
* St. Peter Hauptstraße - 400.000 Treffer in google
* Sankt Peter Hauptstraße - 100.000 Treffer
* St. Michael Eppan - 1,5 Mio. Treffer
* Sankt Michael Eppan - 40.000 Treffer
* St. Johann Tirol - 4,5 Mio. Treffer
* Sankt Johann Tirol - 1,3 Mio. Treffer
* Dr. Müller Straße - 400.000 Treffer
* Doktor Müller Straße - 4.000 Treffer
* Dr. Silvius Magnago - 16.000 Treffer
* Doktor Silvius Magnago - 1 Treffer

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

Re: [Talk-de] St.-ZickeZacke-Str.

[Martin Raifer]

Text-to-Speech


Gute Text-to-Speech Software sollte aber mit diesen Abkürzungen locker  
umgehen können. Und wenn nicht, dann bedarf es für die jeweilige Anwendung  
schlicht eines Post-Processing Schritts, der die Abkürzungen entsprechend  
expandiert.


Wieso es dem Mapper schwer machen wegen möglicherweise schlechter  
Anwendungs-Software? Oder im OSM-Slang: „Wir mappen nicht für das  
Text-to-Speech Programm!“


Martin

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

Re: [Talk-de] St.-ZickeZacke-Str.

[Martin Raifer]

name=Sankt-ZickeZacke-Straße und short_name=St.-ZickeZacke-Straße.


Alternativ: name=St.-ZickeZacke-Straße,  
long_name=Sankt-ZickeZacke-Straße [PS]


Ich würde Straßennamen so schreiben, wie man sie auch in einem  
gewöhnlichen Text (d.h. ohne Platznot wie am Straßenschild), z.B. einem  
Zeitungsartikel schreiben oder lesen würde. Also, Str. ausschreiben,  
Vornamen von Personen ausschreiben. Aber die aller-gebräuchlichsten  
Abkürzungen von z.B. Titeln oder eben das St. für Sankt so stehen  
lassen.


Beispiele:
* Die Wikipedia kürzt in der Liste der Straßennamen von Wien diese auch  
nicht ab [1]

* Ein Zeitungsartikel über die St. Peter Hauptstaße [2]
* Lemmata verschiedener Ortsnamen in der Wikipedia: z.B. St. Pölten [3],  
St. Peter (Graz) [4]


Martin

[PS] Dieses Schema würde sogar noch Luft für ein richtiges short_name  
(z.B. short_name=St.-ZickeZ.-Str.) lassen.

[1] http://de.wikipedia.org/wiki/St._Pölten
http://de.wikipedia.org/wiki/Liste_der_Straßennamen_von_Wien/Döbling#S
[2]  
http://www.kleinezeitung.at/steiermark/graz/graz/2880248/st-peter-hauptstrasse-halbes-jahr-frueher-fertig.story

[3] http://de.wikipedia.org/wiki/St._Pölten
[4] http://de.wikipedia.org/wiki/St._Peter_(Graz)

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

Re: [Talk-de] St.-ZickeZacke-Str.

[Martin Raifer]

Das „war schon immer so“ Argument stimmt nicht. Hier eine schnelle  
Auswertung des aktuellen Stands der

Dinge:

   Sankt   St. [1]
Deutschland  28503072
Österreich6571480
Schweiz   129 565
Südtirol   85 256
-
gesamt   37215373

Es scheint, als hätte sich die Community mittlerweile gegen das  
Ausschreiben von St. entschieden. @Martin K.: Welche “weitreichenden  
Konsequenzen” soll der Status quo denn zur Zeit bitte haben?


Es ist doch immer einer der zentralen Doktrinen von OSM gewesen, dass es  
dem Mapper möglichst einfach gemacht werden soll, während es OK wäre, den  
Auswertern etwas mehr Arbeit aufzubürden. Es geht ja nicht darum, alle  
möglichen exotischen Abkürzungen (oder wirklich unauflösbare Abkürzungen  
von Vornamen) pauschal zu erlauben, sondern eben nur diejenigen, die im  
ganz normalen Sprachgebrauch üblich sind.


Martin

[1] verwendete Reguläre Ausdrücke: /^Sankt[- ]/ und /^St\.[- A-Z]/ –  
gefiltert über alle Ways mit highway=*


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

Re: [Talk-de] St.-ZickeZacke-Str.

[Martin Raifer]

Am 03.02.2014, 18:02 Uhr, schrieb Martin Koppenhoefer  
dieterdre...@gmail.com:



Das erschwert aber international und global betrachtet dennoch extrem die
Auswertung, und macht es für Leute, die den ganz normalen  
Sprachgebrauch
in einem Land nicht kennen, viel schwieriger, was mit den Daten  
anzufangen

(jeweils natürlich nur in dem Fall, dass sie auf einen dieser abgekürzten
Fälle treffen).


Du malst hier ständig den Teufel an die Wand ohne konkrete Probleme  
aufzuzeigen. Kann es sein, dass es die gar nicht gibt?


Ganz davon abgesehen, stimmt es nicht, dass international gesehen keine  
Abkürzungen im großen Stil vorkommen. Und zwar bei den ganzen 1st  
Street, 2nd Avenue, usw. in den USA. Dort schreibt auch niemand First  
Street oder Second Avenue aus, ganz einfach weil das nicht der üblichen  
Schreibweise entspricht. Ganz gleich sehe ich es mit dem St. (auch  
Dr.) bei deutschsprachigen Straßennamen. Diese Abkürzungen sind bei  
Straßen- und Ortsnamen meiner Meinung nach einfach so tief in die  
Orthografie eingebettet, dass eine Verwechslung gar nicht vorkommen kann.


Außerdem: Wenn jemand den ganz normalen Sprachgebrauch eines Landes  
nicht kennt, kann ein ausgeschriebener Name genauso (oder sogar viel eher  
noch) für Verwirrung sorgen: Auf der Karte stünde Sankt Peter  
Hauptstraße, am Schild aber steht St. Peter Hauptstraße[1] – kann man  
ohne deutsche Sprachkenntnis mit einiger Gewissheit sagen, ob das jetzt  
die gemeinte Straße ist? Ich behaupte nein.


Martin

[1] http://666kb.com/i/clj8k92fpwusqpgmg.jpg

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

Re: [Talk-it-southtyrol] Import South Tyrol house numbers in OSM

[Martin Raifer]

Hello,

since you are going to discuss the address import tomorrow at the  
OpenGisData.eu mappers meeting, and I can't be there in person, I'll give  
you some comments here:


1. Less is more

* addr:full tags

I'd just drop the addr:full:* tags, they are of no use here.

* addr:country tags

Drop the addr:country tags, too. This is overly redundant in my opinion.  
The only place where this data may come in handy would be for addresses  
that are very near to the border, but in those cases the addr:country  
could be added by the mapper during the import, if one thinks that it  
makes sense.


* addr:source tags

Drop those. It's good enough to tag the source on the changesets (and the  
import wiki pages). No need for a source tag on every imported datum.


2. Address tagging

I think we've talked about this already [1], but addresses in South Tyrol  
are of two different kinds: a) street-based or b) place-based.


If it is street-based, the addr:street tag must be used (and if available,  
an addr:hamlet can be used optionally to indicate the Fraktion/frazione  
of the address). On the other hand, if an address is place-based the  
addr:place tag must be used and there must be no addr:street tag.


Looking at the test data for Martell, I see that all addresses are  
converted as street-based ones, which is incorrect as most (or all?) of  
them are actually place-based addresses. (See how the addresses in Martell  
are currently tagged.)


I know that the WEGE-DB doesn't directly have this data (and that the data  
is quite inconsistent from one municipality to the next). But that doesn't  
mean that you can import this incomplete data into OSM. The solution to  
this problem is either to program some kind of heuristic that takes nearby  
places into account, or to let mappers decide before or during the import  
(this approach would require a more elaborate importing procedure rather  
than just providing 3 .osm files to import with JOSM).


3. addr:aa2osmid

I think we've talked about this, too. Why do you need other ids to  
represent already unique identifiers? While having external IDs (like GTFS  
stuff, TMC, Gemeindekennzahl, etc.) in OSM is quite bad in principle, this  
particular ID is even worse: There is no accessible external dataset to  
which these IDs correspond to, nobody other than you can check if they are  
still correct, no mapper can know what to put in if new addresses are  
mapped on the ground or if errors are being corrected, etc… Also, see  
point number 1 above (less is more).


I don't see how this field should be necessary in the future. Please show  
me one use-case where this ID is necessary. Until then I'm strongly  
against importing this field.


4. Announce internationally

Please note that you will have to announce this import also on the  
international @imports [2] mailing list. In the last few months there have  
been several other address import proposals which were all heavily  
discussed.


Best regards,
Martin

[1]  
https://wiki.openstreetmap.org/wiki/AltoAdige_-_Südtirol/OpenGisData_HouseNumber_Import2#OSM_tags

[2] https://lists.openstreetmap.org/listinfo/imports

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

Re: [Talk-it-southtyrol] Import South Tyrol house numbers in OSM

[Martin Raifer]

Ciao Pietro!


I'd just drop the addr:full:* tags, they are of no use here.
I don't understand: need to drop only addr:full:it and the addr:full:de  
and taking the addr:full or need to drop addr:full too?


Drop all of them. From the OSM wiki: “Use [addr:full] for [an] address if  
you

find the structured address fields unsuitable for denoting the address of
this particular location.” This doesn't apply to any address in the WEGE
DB as far as I know.


2. Address tagging

I think we've talked about this already [1], but addresses in South  
Tyrol are of two different kinds: a) street-based or b) place-based.


The kinds are 3: a) street-based,  b) place-based  c) both


Really? How does c) look like in real life? Do you have an example?

Looking at the test data for Martell, I see that all addresses are  
converted as street-based ones, which is incorrect as most (or all?) of  
them are actually place-based addresses. (See how the addresses in  
Martell are currently tagged.)


I pay many attenction about this question:  In the Wege DB there are no  
place-based addresses in Martell. This is not an error. All the actually  
place-based addresses are incorrect.
I say this because in the other municipality (for example Bressanone)  
the place-based addresses are correct.

But i'm going to check this problem within tomorrow


I do honestly doubt that. The user who originally mapped the existing
addresses in Martell told me that there are no road names in Martell. (One
can easily confirm this by looking around the town in google streetview.
Also, look at the supposedly street names: Meiern, Ennetal, Sonnenberg,
Gand, … those don't sound like street names, do they?)
For OSM the situation is quite clear: If there are no street signs, the
roads are unnamed. If the roads are unnamed, one cannot use addr:street to
reference these.

I cannot help but to assume that either the WEGE-DB contains slightly
wrong data or describes slightly different things than what we would like
to describe in OSM.


3. addr:aa2osmid
[…]

[…] but if you say that this ID is not necessary, i will drop it.


Huh. I ask you: Why did you want to import it in the first place? It was
you who proposed this field on the import-plan, wasn't you?


Best wishes,
Martin

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

Re: [OSM-talk] Proposed automated edit: remove railway=* or highway=* tag on relations tagged type=route

[Martin Raifer]

Actual numbers would be about 1830 highway=* and about 490 railway=*  
objects with type=route if you count only relations:  
http://overpass-turbo.eu/s/22q


Martin

Taginfo finds type=route combined with 1374 instances of railway=*  
(0.48%) and 6426 instances of highway=* (2.23%).


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

[Talk-it-southtyrol] Barcamp Südtirol 2014

[Martin Raifer]

Hallo!

Am 28./29. März 2014 findet in Meran das Barcamp Südtirol statt:

  http://barcampsuedtirol.org/

Vielleicht hat ja der Eine oder Andere hier Lust, dort mal OpenStreetMap  
unter die Leute zu bringen. Hier sind das speziell Menschen, die irgendwie  
mit Tourismus zu tun haben – in Südtirol ja eine nicht zu  
vernachlässigende Gruppe ;)


Das Barcamp ist eine lockere Veranstaltung. So wie ich das verstanden habe  
im Grunde eine Reihe von kurzen Präsentationen mit anschließenden  
Diskussionsrunden.


Es wäre sicherlich interessant über aktuellen Einsatz von OSM im Bereich  
Tourismus eine Diskussion zu erhalten. Ein Ziel dieser Diskussion könnte  
darin bestehen, zu verstehen ob OSM sich als Instrument für  
Tourismusseiten, Apps, etc. eignet. Welche Vorteile und welche  
Schwierigkeiten der Einsatz von OSM mit sich bringt.



Was sagt ihr dazu?

Schöne Grüße
Martin

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

Re: [Talk-de] Overpass Turbo Wizard findet Relation nicht

[Martin Raifer]

Am 05.01.2014, 22:53 Uhr, schrieb Tirkon tirko...@yahoo.de:


Frage 2: In diesem Beispiel
http://wiki.openstreetmap.org/wiki/Overpass_API/Language_Guide#By_exact_name
findet Overpass OSM-Namen, ohne Nominatim zu bemühen. Kann man meine
Wizard-Abfrage oder die von ihr erzeugte Overpass-Abfrage so abändern,
dass sie diese Methode anwendet?


Ja, du kannst die vom Wizard erzeugten Abfragen beliebig verfeinern. Zum  
Beispiel:



  !-- fetch area “ostfriesische Halbinsel” to search in --
  id-query {{nominatimArea:ostfriesische Halbinsel}} into=area/


Diese Zeile definiert das Suchgebiet für die restliche Abfrage. Hier gibt  
sie an, dass per Nominatim nach einem Gebiet gesucht werden soll.


Das könnte aber auch durch Folgendes ersetzt werden:


  query type=area into=area
has-kv k=name v=ostfriesische Halbinsel /
  /query


Leider ist es aber so, dass das immer noch nicht wirklich weiterhilft,  
weil die von dir gewünschte Relation nicht nur von Nominatim nicht  
ausgewertet, sondern auch von der Overpass API nicht als als Fläche  
erkannt wird. (Möglicherweise wegen dem Tagging als type=boundary ohne  
admin_level?)


Schöne Grüße
Martin

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

Re: [Talk-de] Overpass Turbo Wizard findet Relation nicht

[Martin Raifer]

Am 06.01.2014, 02:31 Uhr, schrieb Tirkon tirko...@yahoo.de:


Ostfriesische Halbinsel ist eine Regionsbezeichnung, die keine
administrative Verwaltungsfunktion und damit keinen admin_level aber
exakt anerkannte Grenzen in Form einer Ansammlung von vier Landkreisen
und zwei kreisfreien Städten hat.


Hm, dann würde ich diese Region anders taggen. Anstatt des type=boundary  
passt wohl eher type=multipolygon mit place=region. Ich war mal so frei…



Da Roland erwähnt hatte, Overpass sei nur einige
Minuten hinter der OSM-DB, habe ich 1,5 Stunden gewartet. Aber leider
blieb das Auslieferungsergebnis leer.


Das stimmt zwar, allerdings sind die Overpass Areas eine Ausnahme, und  
benötigen in der Regel ein paar Stunden zur Aktualisierung. Siehe den  
aktuellen Stand der Daten (um ca. 07:34 UTC):



   timestamp_osm_base: 2014-01-06T07:33:02Z,
   timestamp_areas_base: 2014-01-05T16:31:01Z,


PS: Diese Information bekommt man automatisch von der Overpass API zu  
jeder Query mitgeliefert. In overpass turbo einfach auf den Daten-Tab  
wechseln.


Grüße
Martin

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

Re: [Talk-de] Gzip von der Overpass API

[Martin Raifer]

Am 10.12.2013, 14:54 Uhr, schrieb Manuel Reimer  
manuel.s...@nurfuerspam.de:


Ich hoffe ihr prüft vorher ab ob der anfragende Browser auch GZIP  
unterstützt.


Ja, das funktioniert. Vergleiche:

$ curl -v http://overpass-api.de/api/interpreter?data=node(666);out;
$ curl -v http://overpass-api.de/api/interpreter?data=node(666);out; -H  
Accept-Encoding: gzip


Grüße
Martin

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

Re: [Talk-at] Haltestellendaten Steiermark

[Martin Raifer]

Hallo Andreas,

ich habe deine Mail [1] auf der imports-Liste (betereffend des is_in-Tags)  
gesehen, und gedacht ich antworte erstmal nur hier, weil einige Sachen  
doch ziemlich lokal sind.


I think the is_in is necessary for the following reason: We only have  
boundaries down to the level of communities (Gemeinden) in OSM, but  
the bus stops are often labelled with the name of villages, sub-parts of  
the communities, which sometimes don't even have exact boundaries.
Here are some examples, where I think it would be impossible to derive  
the complete name (town and name of stop) without the is_in-tag:


http://www.openstreetmap.org/node/1487738866: Although this stop is  
geographically still in the city of Graz, this stop is in Fölling for  
everything related to public transport (most important for tariffs, but  
also for a unique name ...).
http://www.openstreetmap.org/node/1801654560: This stop is closer to the  
node called Fölling in OSM than the above stop, however it is in  
Prellerberg (there is not even a place in OSM with that name).


Also, das Beispiel mit Fölling ist nicht ganz gut gewählt, weil es neben  
dem kleinen Fölling in Weinitzen auch noch das etwas größere Fölling bei  
Mariatrost gibt (welches aber bis gerade eben in OSM gefehlt hat). Auf  
dieses 2. Fölling beziehen sich aber die Verbundlinie-Daten (siehe:  
Fölling bei Graz).


http://www.openstreetmap.org/node/1735061993: This stop is named after  
the community it is in: Rettenegg, BUT:
http://www.openstreetmap.org/node/1735061989: This is the platform for  
the other direction, which of course has the same name, but is  
geographically already beyond the border in the next community (Sankt  
Jakob im Walde).


Die Rohdaten enthalten hier nur Rettenegg (Stmk). Das vollständige is_in  
hast du dir daraus zusammengebastelt, oder? Hier ist das Problem, das ich  
darin sehe: Es gibt dort nur eine Ortschaft namens Rettenegg  
(http://www.openstreetmap.org/node/240078095, zugleich Gemeinde  
Rettenegg). So etwas wie Rettenegg,Sankt Jakob im Walde,… gibt es nicht,  
die is_in-Information der 2. Haltestelle ist also schlicht falsch.


Ähnliches z.B. hier: http://www.openstreetmap.org/node/728306183: In  
Kainbach gibt es kein Graz mehr.


One could of course state, that the bus stops should be renamed, but  
since that is not within our scope, I still think, the is_in-tag is  
required for identificaiton of the bus stops.


Ich bin nicht überzeugt, dass is_in das richtige Tag hierfür ist. Denn:  
is_in gibt die geographische Zugehörigkeit eines Objekts an (“The is_in  
tag is used to index where a place or feature is.”). Zum Beispiel, um  
sicher anzugeben, dass ein Berggipfel in Land A ist, ohne dass die Grenze  
zwischen Land A und Land B genauer bekannt ist.


Ich denke, dass das was bei diesem Import als Ort angegeben ist, nicht  
viel mit echten Orten gemein hat. (Du sagst ja selbst, dass diese Orte  
nur im ÖPNV-Kontext relevant sind). Es sind wohl eher einfach  
Tarifzonen-Unterteilungen. Wenn ich also beispielsweise von einer  
Haltestelle abfahre, die als Ort Fölling hat, kann ich mit einem  
1-Zonen-Ticket sowohl nach Graz (Zone 101) als auch in die Zone 203  
fahren. Das erklärt auch, wieso einige Haltestellen in der Ragnitz noch  
als Ort Graz haben.


Dafür das is_in-Tag zu missbrauchen, finde ich nicht gut. Ich würde eher  
vorschlagen, ein eigenes Tag dafür zu finden (vielleicht gibt es ja schon  
etwas). Wenn man möchte, könnte man dann auch noch für den vollständigen  
Namen der Haltestellen ein alt_name=Ort HST-Name hinzufügen.


Liebe Grüße
Martin

[1]  
https://lists.openstreetmap.org/pipermail/imports/2013-December/002455.html


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

Re: [Talk-at] Haltestellendaten Steiermark

[Martin Raifer]

Am 28.11.2013, 09:12 Uhr, schrieb Stefan Tiran  
stefan.ti...@student.tugraz.at:



Die Haltestellennummer ist auch auf den Aushängefahrplänen (rechts oben)
ersichtlich und daher sehrwohl erkenn- und überprüfbar.


Hm. In Graz jedenfalls nicht: http://666kb.com/i/cjn9l2o2uvc5i0eih.jpg
Und wenn, dann ist wahrscheinlich auch nur die Haltestellen-Nummer und  
nicht die z.Z. als ref vorgesehene IFOPT-Nummer angegeben, oder?


Grüße
Martin

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

Re: [Talk-de] Wo bekommt man Satellitenbilder von Sardinien. Zyklon Unwetter

[Martin Raifer]

Hallo!

Was die Unwetterschäden angeht: Die italienische Community hat einen  
HOT-Task eingerichtet: [2]. Außerdem wird seit Kurzem daran gearbeitet,  
Geo-Daten der Autonome Region Sardinien [3] zu importieren [4], die heute  
für OpenStreetMap zur Verfügung gestellt wurden [5].


wo bekommt man Satellitenbilder von Sardinien um hier in OSM Updates  
einzuarbeiten?


Suchst du etwas spezielles? Denn eigentlich sollte die ganze Insel von  
Bing recht hochaufgelöst abgedeckt sein. Dazu gibt es noch die auch recht  
guten Luftbilder von PCN (Portale Cartografico Nazionale) [1], die aber  
leider schon etwas älter (2006) sind.


Martin

[1] https://wiki.openstreetmap.org/wiki/WikiProject_Italy/PCN
[2] http://tasks.hotosm.org/job/367
[3] http://www.sardegnageoportale.it/catalogodati/download/
[4]  
https://lists.openstreetmap.org/pipermail/imports/2013-November/002370.html

[5] https://twitter.com/simonecortesi/status/403505608831168512

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

Re: [Talk-at] Haltestellendaten Steiermark

[Martin Raifer]

Am 19.11.2013, 20:29 Uhr, schrieb Manfred Brandl manf...@brandl.net:


Bevorrechtigter-IV (Busse) ist möglicherweise zu oft gesetzt.


Kann es sein, dass auch andere Verkehrsmittel zu oft gesetzt sind?  
Beispielsweise hat die Haltestelle Styriastraße (IFOPT: at:46:4765:0:murp)  
das Attribut Eisenbahn=Ja.


Soweit ich mich erinnere habe ich nur Haltestellenpositionen exportiert  
bei denen wirklich etwas vorbeifahren sollte. Das bedeutet aber nicht  
immer zwingend, dass die Haltestellenposition auch als solche erkennbar  
ist. Manche Haltestellenpositionen wird auch nur sehr selten ( einmal  
jährlich ) bedient.


Spontan fällt mir auf, dass Haltestellen, die vor Kurzem verlegt wurden,  
doppelt enthalten sind. Siehe z.B. die Tramhaltestelle  
Esperantoplatz/Arbeiterkammer.


Schöne Grüße
Martin

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

Re: [Talk-at] Haltestellendaten Steiermark

[Martin Raifer]

Servus.

Klingt super!

Ich habe zufälligerweise vor ein paar Wochen einen ähnlichen  
Haltestellen-Datensatz importiert: [0], vielleicht kannst du dich etwas  
daran orientieren.


Aber leg doch bitte erst mal eine Wiki-Seite für den Import an (siehe  
[1],[2]). Hier in der E-Mail ist das Ganze leider sehr unübersichtlich.


Die nicht mehr bestehenden Haltestellen herauszufiltern halte ich für  
unbedingt notwendig. Dafür müssen wir uns irgend eine Lösung einfallen  
lassen.


Was das Tagging angeht würde ich folgendes vorschlagen (wobei ich anmerken  
muss, aus Zeitgründen erstmal nur die bereits konvertierten Daten, also  
haltestellen-mitosmtags.osm angeschaut zu haben):


* no-Werte (z.B. ferry=no, subway=no) weglassen.
* Es gibt Punkte, die für alle Transportmittel den wert no haben. Diese  
sollte man wahrscheinlich herausfiltern.
* is_in: wieso? Außerdem scheinen die Werte teilweise auch nicht ganz  
richtig zu sein.
* loc_name / loc_ref: Mir erschließt sich nicht der Nutzen dahinter nicht  
(siehe auch meine Anmerkungen zu ref weiter unten).
* ref:RBL: Dito. Außerdem haben alle Haltestellen eine solche ID, also  
auch solche, die gar keine RBL-Anzeige haben. Interessant wäre lediglich  
diese Information (~display_panel~ = yes/no), irgendwelche  
Unternehmens-interne IDs interessieren keine Sau.
* ref: Würde ich nicht importieren. Solche Daten sind später sehr schwer  
zu erhalten, außerdem sind die Daten praktisch nutzlos (und wenn wirklich  
jemand diese Unternehmens-internen IDs benötigen sollte, kann er auch auf  
die Originaldaten zugreifen, dafür müssen sie nicht in OSM sein). In der  
Vergangenheit wurden solche IDs oft einfach ohne zu überlegen importiert,  
und stellen bis Heute einen nicht zu vernachlässigenden Ballast dar. Es  
ist schon so weit, dass diese Daten mühsam wieder nachträglich entfernt  
werden: [3],[4] (siehe außerdem dazu noch die Diskussion auf talk-de über  
die IFOPT-IDs [5]).
* ref:stop_area: Würde ich aus den selben Gründen nicht importieren. Zur  
Identifikation von zusammengehörigen Haltestellen dient ja bereits deren  
identischer Name.


Was den Import-Ablauf angeht würde ich sagen, dass ein zweigeteilter  
gebufferter Ansatz, so wie du ihn beschreibst, gut funktionieren könnte.  
Es wird aber trotzdem recht viel manuelles Intervenieren notwendig sein.  
Evtl. könnte man sich mal das Import-Tool OSMLY [6] ansehen.


Schöne Grüße
Martin

PS: Nicht vergessen diesen Import auch noch auf impo...@openstreetmap.org  
anzukündigen.


[0]  
https://wiki.openstreetmap.org/wiki/AltoAdige_-_Südtirol/SASA_Bus_Stops_Import
[1]  
https://wiki.openstreetmap.org/wiki/Import/Guidelines#Step_3_-_Documentation

[2] https://wiki.openstreetmap.org/wiki/Import/Plan_Outline
[3] Discarding IDs imported with US-Tiger data:
http://gis.19327.n5.nabble.com/Discardable-TIGER-tags-td5718873.html
[4] Discarding IDs imported with KSJ2 data:
https://lists.openstreetmap.org/pipermail/imports/2013-September/002133.html
[5] https://lists.openstreetmap.org/pipermail/talk-de/2013-July/103225.html
[6] https://wiki.openstreetmap.org/wiki/OSMLY


Am 19.11.2013, 07:45 Uhr, schrieb Andreas Uller a.ul...@gmx.at:


Hallo!

Vom Verkehrsverbund Steiermark haben wir Daten zu allen ÖV-Haltestellen  
in der

Steiermark zur Verwendung in der OSM erhalten.

Die Daten sind derzeit hier gespeichert:  
https://github.com/species/Open-Data-Verbundlinie.at


Die Lagegenauigkeit ist auf jeden Fall brauchbar, mir sind nur wenige
Haltestellen aufgefallen, deren Position nicht genau passt (und auch da  
sind's

nur ein paar Meter daneben).

Größter Nachteil aus meiner Sicht: Es sind offenbar auch ehemalige  
Haltestellen

drinnen, die nicht mehr bedient werden (und vor Ort auch nicht mehr als
Haltestellen ersichtlich sind). Auch wenn da vielleicht noch eine  
Konzession
existiert, dienen solche nicht-sichtbaren Haltestellen meiner Meinung  
nach nicht

der Orientierung und sollten dann auch nicht in OSM dargestellt werden.
Vielleicht hat der Verkehrsverbund da aber noch eine Liste, welche  
Haltestellen

tatsächlich bedient werden und welche nicht.

Die Attribute der Haltestellen sind natürlich nicht OSM-konform, in  
Folge mal

meine Analyse der vorhandenen Daten und wie wir das in OSM-Tags umwandeln
könnten, bitte um Kommentare!

Für den oft bereits vorhandenen Tag ref für die Bezeichnung der Bus- bzw.
Bahnsteige (A, B, C, ..., 1, 2, 3, ...) würde ich eine Umbenennung auf  
loc_ref

vorschlagen.

Aushangfahrplan: Ist außer bei einer Haltestelle immer Nein - löschen

Bereich Nr.: Hier sind bei größeren Haltestellen mehrere Haltepositionen  
die in
unmittelbarer Nähe liegen zusammengefasst (z.B. Jakominiplatz: 3/6  
Richtung

Dietrichsteinplatz und 1/7 Richtung Kaiser-Josef-Platz sind ein Bereich,
Richtung Hauptplatz ist aber ein eigener Bereich) - mMn für OSM nicht  
relevant

- löschen

Bevorrechtigter IV (Busse): Ob Busse diese Haltestelle anfahren -  
bus=yes/no


Buchsatz: Ist außer bei einer Haltestelle 

Re: [Talk-at] ID_wo_ist_geoimage

[Martin Raifer]

Zur Info: Ab jetzt sollte geoimage.at in Österreich wieder als Layer im  
iD-Editor zur Auswahl stehen.


Martin

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

[Talk-it-southtyrol] Fwd: [Talk-it-trentino] Workshop su OSM in Trentino

[Martin Raifer]

Domani (13 novembre) @Rovereto – Workshop su OSM in Trentino:


Il 11 novembre 2013, Cristian Consonni kikkocrist...@gmail.com ha  
scritto:


# Workshop OSM Academy trentino: imparare a contribuire a OpenStreetMap

siamo un gruppo di mappatori trentini e volevamo segnalarti che stiamo
organizzando un workshop sull'utilizzo di OpenStreetMap. Ci saranno
delle presentazioni (di livello introduttivo) e faremo insieme un po'
di modifiche alla mappa.

Il Workshop si terrà a Rovereto dalle ore 18:00 alle ore 21:00, presso
l'Uban Center di Rovereto in Corso Rosmini 58
([mappa](http://www.openstreetmap.org/browse/node/2381015677) e
[sito](http://www.urbancenter.rovereto.tn.it/)).

Maggiori informazioni sono disponibili alla [pagina di
Rovereto](http://wiki.openstreetmap.org/wiki/Rovereto#Workshop) sul
wiki di OpenStreetMap.

Speriamo sarai dei nostri.

i mapper della lista talk-it-trentino

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

Re: [OSM-talk] Overpass area query gives results outside area...

[Martin Raifer]

Hi!


As an exercise, let's find Dakar in Senegal


Searching areas by area is not yet supported in Overpass API. See this  
feature request:


  https://github.com/drolbr/Overpass-API/issues/45

Well... Maybe area selection is inoperative. Let's try with a good old  
bounding box


This is also not yet implemented, unfortunately:

  https://github.com/drolbr/Overpass-API/issues/55


If you only want to get the administrative area Dakar: Why not simply  
using something like this:


  area[name=Dakar][boundary=administrative];
  out;

This works as long as there isn't another city with the same name  
somewhere else.


Martin

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

Re: [Talk-de] path am Strand fuer den Router ...

[Martin Raifer]

Der Weg existiert ja defakto nicht.


Doch.

Ich sehe keinen großen Unterschied zu (teilweise) weglosen Wanderrouten im  
Gebirge. Einfach ein entsprechendes trail_visibility-Tag [1] dranhängen  
und jeder versteht was gemeint ist (hier könnte z.B. good passen, falls  
die Route ansonsten gut durch Wegweiser markiert ist).


Die permanente Existenz einer Wegspur sollte keine notwendige  
Voraussetzung für einen Weg i.S.v. OSM sein. Ansonsten dürfte es so etwas  
wie [2] nicht geben, man müsste Wanderwege an Furten zwischen den beiden  
Ufern auftrennen, und und und.


Martin

[1] https://wiki.openstreetmap.org/wiki/DE:Key:trail_visibility
[2] http://www.openstreetmap.org/browse/way/32845237

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

Re: [Talk-at] Basemap.at

[Martin Raifer]

 http://maps.wien.gv.at/basemap/geolandbasemap/normal/google3857/%1/%3/%2.jpeg

 Wenn ich auf Get Services klicke, kommt eine Messagebox: Download failed: 
 Not Found

Das kannst du ignorieren, weil das schon die fertige URL ist (dann ist
das get services nicht notwendig).
Bei mir funktionierts jedenfalls: http://666kb.com/i/cipdxlm73u3gmolc3.jpg

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

Re: [Talk-at] Basemap.at

[Martin Raifer]

Welche URL gibt man dann in Merkaartor ein?


Versuchs mit Folgendem:

  http://maps.wien.gv.at/basemap/geolandbasemap/normal/google3857/%1/%3/%2.jpeg

Martin

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

Re: [OSM-talk] Mapping of multiple-lane toll areas

[Martin Raifer]

There is another complication with this kind of lane mapping: At many  
motorway toll areas, not all toll booths are open all the time. Often even  
the allowed traffic direction through the individual booths is changed  
dynamically to meet asymmetric demand!


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

Re: [Talk-de] Mannheim - Quadratenamen in Mapnik verschwunden

[Martin Raifer]

Hallo Bernhard,

das ist eine etwas komplexere Geschichte.

Das OSM-Stylesheet (sowohl das alte “Mapnik-XML”[1] als auch das neue  
openstreetmap-carto[2]) haben noch nie Ortschaften mit  
`place=neighbourhood` gerendert (es gibt aber bereits einen Patch, der das  
in Zukunft hinzufügen soll: [3]). Zugleich haben beide Stylesheets einen  
Bug, der die Namen von benannten Flächen darstellt, außer wenn diese ein  
`place`-tag haben [4].


Bevor rayquaza die Adressen überarbeitet hat, waren die Quadranten als  
`area=yes` mit z.B. `name=T2` (siehe [5]) eingetragen. Das war eindeutig  
unerwünschtes “Taggen für den Renderer”.



Was ist zu tun, dass die Namen wieder angezeigt werden?


Im Moment bleibt nur das Abwarten, bis `place=neightbourhood` korrekt im  
Stylesheet implementiert ist.[3]


Martin

[1] https://github.com/openstreetmap/mapnik-stylesheets
[2] https://github.com/gravitystorm/openstreetmap-carto
[3] https://github.com/gravitystorm/openstreetmap-carto/pull/28
[4] https://github.com/gravitystorm/openstreetmap-carto/issues/240, siehe  
auch https://github.com/gravitystorm/openstreetmap-carto/issues/1

[5] http://www.openstreetmap.org/browse/way/194898771/history

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

Re: [Talk-de] Mannheim - Quadratenamen in Mapnik verschwunden

[Martin Raifer]

Am 19.10.2013, 11:22 Uhr, schrieb Martin Koppenhoefer  
dieterdre...@gmail.com:


m.E. nicht. area=yes sagt, dass es ein Polygon ist (richtig) und name  
gibt den Namen an (auch richtig). Das einzige was man an dem Tagging  
kritisieren könnte ist, dass es unvollständig ist (es ist keine 
spezifische Objektklasse/typ angegeben).


Ich meinte, dass das Tagging wohl bewusst unvollständig gehalten wurde um  
das Rendering des entsprechenden Namens sicherzustellen. Denn dass die  
Quadranten einem place-Tag entsprechen ist doch sehr naheliegend (ob jetzt  
`place=neighbourhood` oder `place=block` oder was auch immer sei mal  
dahingestellt).


Martin

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

[Talk-at] Willkommens-Nachricht

[Martin Raifer]

Am 16.10.2013, 10:54 Uhr, schrieb Andreas Labres l...@lab.at:

Was ev. auch sinnvoll wäre: einen für ganz Österreich gültige  
Willkommens-Nachricht jedem schicken, der neu etwas macht. Müßte nur  
sehr kurz sein, daher wohl zweistufig, also mit einem Link auf eine  
Willkommen-Seite, wo dann weitere Infos stehen.


Die Italiener schicken seit Anfang 2013 Neu-Usern die folgende  
Willkommens-Nachricht:


  https://wiki.openstreetmap.org/wiki/User:Sarchittuorg/Benvenuto

Wenn ich das richtig in Erinnerung habe, läuft das Ganze automatisch per  
Bot ab. Der folgende Account versendet jedenfalls die Nachrichten:  
http://www.openstreetmap.org/user/OSM%20Italia


Falls man das auch in Österreich einführen möchte, würde es sich anbieten  
sich mit Stefano (http://www.openstreetmap.org/user/sabas88)  
kurzzuschließen.


Grüße
Martin

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

Re: [Talk-at] Forum statt Mailingliste

[Martin Raifer]

Am 16.10.2013, 07:06 Uhr, schrieb Michael Maier  
michael.ma...@student.tugraz.at:

Nein! Nein! Nein!



Ich kann nur von mir persönlich sprechen, aber für mich war die  
Mailingliste sehr lange der Grund mich nicht stärker in OSM zu  
engagieren. Anstatt mich öfter mich mit Anderen auszutauschen habe ich  
einfach lange mein eigenes Süppchen gekocht bzw. nur über persönliche  
OSM-Nachrichten Ideen ausgetauscht.


Ich finde, dass Mailinglisten im Allgemeinen nicht unbedingt der  
Kommunikation förderlich sind, für ein so heterogenes Projekt wie OSM.  
Hier ein paar Gründe, wieso ich das denke: (1) Mailinglisten haben ein  
antiquiertes Image und sind viel zu kompliziert zu bedienen. (2) Man wird  
mit Nachrichten zwangsbeglückt (nichteinmal ein opt-out aus Threads ist  
möglich). (3) Man kann praktisch nicht auf vergangene Nachrichten  
antworten, die vor der eigenen Anmeldung an die Liste erstellt worden. (4)  
Nachrichten können nicht korrigiert oder ergänzt werden.


Punkt (1) führt dazu, dass nur technisch versierte Benutzer sich überhaupt  
anmelden.
Punkt (2) führt dazu, dass man sich auch als technisch Versierter eher  
nicht anmeldet, wenn einem nur gewisse Themen einer Liste interessieren  
würden. Außerdem ist nicht Jeder zu 100% in OSM involviert und möchte  
Jeder Diskussion folgen. Wenn man als Neuling nur eine kurze Frage hat,  
aber nach der Anmeldung täglich dutzende Mails eintrudeln fühlt man sich  
schnell vollgespamt.
Punkt (3) ist einfach nur lästig und führt dazu, dass Threads regelmäßig  
zersplitten.
Punkt (4) führt dazu, dass man sich jedes Posting mehrmals überdenkt. Wenn  
man keine Möglichkeit hat, nachträglich Fehler auszubessern, oder seinen  
Standpunkt inhaltlich zu ergänzen, überlegt man sich 3 mal ob man  
überhaupt etwas posten möchte. So geht es mir gerade bei diesem Posting.


Damit finde ich, dass damit eine Mailingliste alles andere als eine  
freundliche Umgebung für allgemeine Diskussionen für eine heterogene  
Gruppe von Leuten ist.


(Eine Mailingliste mag ja vielleicht das Richtige für die  
Linux-Kernel-Entwickler sein (technisch versierte Leute, im allgemeinen  
alles Leute die sehr stark engagiert sind und man möchte bewusst nicht  
freundlich für Neulinge sein um das Niveau der Diskussionen hoch zu  
halten). Aber eben nicht für OSM talk.)


Dies wird unterstützt durch die Erfahrungen, die ich bisher im OSM-Forum  
gemacht habe. Außerdem habe ich schon von mehreren Leuten gehört, dass  
sich diese bewusst nicht an Diskussionen beteiligen mochten, weil diese in  
einer Mailingliste stattfinden…



Patentlösung für dieses Problem habe ich natürlich keine. (Sicher hat die  
Mailingliste auch ihre Vorteile und Foren ihre Nachteile.) OSM ist aber  
wohl groß genug, mehrere Diskussionsplattformen parallel zu haben. Eine  
Möglichkeit wäre dann z.B. das Germany-Forum in  
Germany-Austria-Swizzerland umzubenennen.


Ich finde aber, dass es am wichtigsten ist zu verstehen und zu  
akzeptieren, dass in den Mailinglisten hauptsächlich nur Hardliner aktiv  
sind, und dadurch Diskussionsergebnisse nicht mehr unbedingt repräsentativ  
sind. (Gerade deswegen bin ich der Meinung, dass Abstimmungen, Umfragen,  
o.Ä. wenn immer möglich vermieden werden sollen. Denn wir paar Hansln auf  
der Mailingliste können nie und nimmer für alle Mapper entscheiden. Was  
wir aber machen können ist diskutieren und aufgrund von objektiven  
rationalen Begründungen einen Konsens finden.)



Mit liebsten Grüßen
Martin, der noch ein letztes mal überlegt, diese Mail trotzdem nicht  
abzusenden.



PS: Ist euch bewusst, dass das Diskussions-Volumen in den  
OSM-Mailinglisten seit einigen Jahren rückläufig ist, obwohl OSM  
klarerweise immer noch wächst? Woran das wohl liegen wird?


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

Re: [Talk-at] Abstimmung?: Wie man Begegnungszonen in Österreicht taggt

[Martin Raifer]

Ich kann mich deiner Analyse und Beurteilung nur anschließen!

Allerdings finde ich nicht, dass eine Abstimmung zu diesem Zeitpunkt  
unbedingt notwendig ist. Denn ich hatte nicht den Eindruck, dass sich die  
Diskussion bereits derart verfahren hat, dass ein Konsens nicht mehr  
möglich wäre.


Ganz liebe Grüße
Martin


Am 10.10.2013, 20:09 Uhr, schrieb Markus Straub  
markus.straub...@gmail.com:



Hallo,

ich würde gerne eine Abstimmung starten, wie wir in Österreich  
Begegnungszonen taggen - ausgehend von der Diskussion letzte Woche.


Bitte lest meine Ausführungen im P.S.-Teil nochmals.

Wenn wir uns einigen können würd ich es ins Wiki eintragen, sodass sich  
1) alle Mapper und 2) alle die die Daten verwenden wollen auskennen und  
wir *eine* Tagging-Variante haben.



Die Varianten:

(1) highway=pedestrian  + maxspeed + access
(2) highway=living_street   + maxspeed
(3) highway=residential + maxspeed + 'shared_space'

LG,
Markus


P.S.: Anbei noch meine längliche Begründung, warum imho Variante (2) die  
beste ist.


Ich plädiere für (2), weil
- wir in Österreich kurioserweise zwei Varianten von dem, was  
international Woonerf (NL), Wohnstraße (DE) und Begegnungszone (CH)  
genannt wird, haben. Und in OSM bis dato highway=living_street genau das  
meint. Jedes Land mit seinen eigenen Regeln, und bei uns jetzt in zwei  
Ausformungen.
- pedestrian imho zu stark ist, weil es alles außer Fußverkehr  
standardmäßig ausschließt
- residential imho zu schwach und eine Begegnungszone mit Tempo 30  
nicht von einer normalen Straße mit Tempo 30 unterschieden werden kann,  
weil es (noch) keinen offiziellen Tag wie shared_space=yes gibt.



Variante (2) ist kompatibel mit den alten Wohnstraßen, und durch  
einfaches setzen von maxspeed bei neuen Begegnungszonen kann man sie für  
die Auswertung (z.B. Routing) klar unterscheiden. Im Standardrendering  
ist zusätzlich auch klar, dass eine Begegnungszone verkehrsberuhigt ist.


Im Detail noch kurz erklärt, wie man Variante (2) auswerten für z.B.  
einen Router auswerten kann:



Wohnstraße (AT)
===

highway=living_street
(oneway=yes)

-- wird als Wohnstraße erkannt durch fehlende maxspeed oder  
maxspeed=AT:walk/5/7

-- muss (z.B. fürs Routen) ergänzt werden zu

highway=living_street
maxspeed=AT:walk (bzw mit einem echten Wert wie 5,7,...)
motor_vehicle=destination
(oneway=yes)
(oneway:bicycle=no)


Begegnungszone (AT)
===

highway=living_street
maxspeed=20
(oneway=yes)

-- wird als Begegnungszone erkannt durch maxspeed=20/30
-- muss (z.B. fürs Routen) nicht ergänzt werden

highway=living_street
maxspeed=20
optional: oneway=yes



Anbei noch ein paar Links zur Wohnstraße [1], dem Nebeneinanderfahren  
von Radfahrern [2], Regeln für Radfahrer auf verschiedenen Straßentypen  
[3] und der Begegnungszone [4]. Shared Space ist eine andere Diskussion,  
leider gibt es soweit ich weiß noch kein Proposal diesbezüglich.


[1] http://www.jusline.at/76b_Wohnstra%C3%9Fe_StVO.html
[2]  
http://www.jusline.at/index.php?cpid=ba688068a8c8a95352ed951ddb88783elawid=24paid=68
[3]  
https://www.help.gv.at/Portal.Node/hlpd/public/content/194/Seite.1940026.html

[4] http://www.kfv.at/verkehr-mobilitaet/begegnungszone/

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


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

Re: [Talk-de] ID

[Martin Raifer]

Am 03.10.2013, 17:18 Uhr, schrieb Wolfgang Hinsch:


Die Einstellung bei mir ist de-DE,en-US,en

Die OSM-Webseite läuft komplett auf Deutsch. Der ID läuft komplett auf
Englisch.


Mit dieser Einstellung läuft bei mir (ebenfalls FF20) sowohl die  
OSM-Webseite als auch iD auf Englisch. Und das wäre gemäß deiner  
Einstellung im Prinzip auch nicht falsch (weil es keine  
Deutschland-Deutsche Übersetzung weder von der OSM-Webseite  noch von iD  
gibt) und du explizit eingestellt hast, dass die generisches  
Deutsch-Übersetzung nicht verwendet werden soll.


Unerklärbar ist mir aber wieso bei dir die Webseite trotzdem auf Deutsch  
läuft. Kann das sonst noch jemand nachvollziehen?


Martin

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

Re: [Talk-de] ID

[Martin Raifer]

Hallo!

Am 02.10.2013, 19:14 Uhr, schrieb Wolfgang Hinsch  
osm-lis...@ivkasogis.de:



der ID hat eine nette Einführung für Anfänger. Gibt es das auch auf
Deutsch oder ist eine Übersetzung geplant? Weiß jemand näheres?


Welche Einführung meinst du konkret?

Wenn du die interaktive Schritt-für-Schritt Einführung (direkt im iD  
Editor) meinst, dann sollte diese eigentlich bereits (seit Längerem)  
komplett übersetzt sein.



Das würde die Hemmschwelle bei Vielen deutlich senken.


Ja! Alles was eventuell bestehende Hemmschwellen gegen das Beitragen bei  
OSM senken kann ist eindeutig nur positiv zu sehen! :)


Martin

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

Re: [Talk-de] ID

[Martin Raifer]

Am 03.10.2013, 00:49 Uhr, schrieb Wolfgang Hinsch  
osm-lis...@ivkasogis.de:



Dann hat diese Übersetzung bei mir keine Auswirkungen. Eine Einstellung
der Sprache habe ich nicht gefunden. Ich sehe nur den englischen Text.


Hm. Komisch. iD übernimmt eigentlich die Sprache, die im OSM-Account  
(unter Bevorzugte Sprachen bzw. Preferred Languages) eingestellt ist.  
Ist das bei dir Deutsch (bzw. de oder de-DE)? Wird die restliche  
OSM-Website auf deutsch angezeigt? Ist nur die Einführung/Walkthrough  
nicht übersetzt, oder die gesamtem Benutzerelemente von iD?


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

[OSM-talk] overpass turbo: translators seeked

[Martin Raifer]

Hi all!

I've just released a new version of overpass turbo, the online OSM  
data-mining tool based on the Overpass API. You can read about some of the  
new features (especially exporting data as Gists and using that for  
geojson.io) on my blog:  
http://www.openstreetmap.org/user/tyr_asd/diary/20043


Furthermore, its user interface translations are now on Transifex and I'm  
looking for translators! If you'd like to help translate, simply create an  
account on Transifex (if you don't already have one) and head over to the  
project page:  
https://www.transifex.com/projects/p/overpass-turbo/translate/


Thanks and best wishes,
Martin

PS: Just drop me a message if you want me to activate another language if  
it's not already on the list.


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

Re: [OSM-talk] Making iD the default editor on osm.org

[Martin Raifer]

Please, do not offer a delete function that prominent !


This has come up before. Where should this action button move? Or should
there be an alert message? How to resolve this with pro users who get  
angry with how hidden or alert-messaged the functionality is? Would

welcome feedback here beyond the simple negative.


What about requiring double clicks on the delete icon to make sure a user  
didn't accidentally click the icon. And at the same time only showing a  
tooltip on single clicks: Are you sure you want to delete this item?  
Double click to delete.
That way power-users can go on with their deletions without a substantial  
barrier, but newbies are much less likely to accidentially delete things.

Variations: Require shift-click or crtl-/option-click on the delete button.

I know, this isn't an already well established UI pattern, though. :/

Cheers.
Martin

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

Re: [Talk-de] Darstellungsfehler im Rendering. Wie Fehler melden?

[Martin Raifer]

Am 12.08.2013, 10:45 Uhr, schrieb Martin Koppenhoefer  
dieterdre...@gmail.com:


gab es da vielleicht irgendwo eine Regression ? [...] früher dieses  
Problem der abgeschnittenen Labels [...] nur sehr selten


Ich habe auch diesen Verdacht. Besonders auffällig ist Das bei den  
ref-shields sichtbar, die mit dem alten OSM-Mapnik-Stil so gut wie nie  
abgeschnitten wurden, jetzt aber leider recht häufig:


http://bl.ocks.org/tyrasd/raw/6164696/#12.00/46.5124/11.3431

Grüße
Martin

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

Re: [Talk-de] Darstellungsfehler im Rendering. Wie Fehler melden?

[Martin Raifer]

Am 12.08.2013, 13:33 Uhr, schrieb Sven Geggus  
li...@fuchsschwanzdomain.de:



Martin Raifer tyr@gmail.com wrote:


Ich habe auch diesen Verdacht. Besonders auffällig ist Das bei den
ref-shields sichtbar, die mit dem alten OSM-Mapnik-Stil so gut wie nie
abgeschnitten wurden, jetzt aber leider recht häufig


Martin redet von Mapnik/tirex/renderd und nicht vom OSM Kartenstil  
selbst.

Wie gesagt, der deutsche Stil ist bisher nicht carto basiert.


OK, mit altem OSM-Mapnik-Stil meinte ich eigentlich den gesamten  
Rendering-Stack. Sorry.
Martin vermutete, dass es irgendwo eine Regression gegeben hätte. Und  
seine Symptome (die er seit ca. 1 Jahr bemerkt) sieht man jetzt auch im  
aktuellen OSM-Rendering.
Wenn ich nicht irre, wurde auf osm.org kürzlich auch Mapnik auf eine neue  
Version upgedatet. Es könnte ja mittlerweile ein aggressiverer  
Label-Placement-Algorithmus im Einsatz sein und es deswegen zu so viel  
mehr Artefakten kommen?


Soweit mein Senf zu der Sache
Martin

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

Re: [Talk-de] Autokennzeichen

[Martin Raifer]

Am 09.08.2013, 19:35 Uhr, schrieb Christian Hauer xni...@gmail.com:


Oft aber auch schon.
[...] Italien


Nein, in Italien auch nicht (bzw. schon länger nicht mehr).

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