Re: [OSM-talk] Name challenge - what to call the new OSM+Wikidata service?

[Florian Schäfer]

Hi,
my suggestion would be WOQ (pronounced like "Wok"), which would be short
for "Wikidata-OSM-Queryservice". Or WOQs, if you don't want to only use
one letter for "query" and "service".
The soundalike word "Wok" could also in my opinion be a good metaphor,
you can put Wikidata and OSM data "into a Wok" and "cook" something new
out of it. Maybe the logo could then be a Wok containing map elements
like highways, rivers, forests and so on and also something representing
Wikidata (like the colourful barcode).

Cheers,
Florian

Am 16.09.2017 um 23:11 schrieb Yuri Astrakhan:
> The new service is getting more and more usage, but it lacks the most
> important thing - a good name.  So far my two choices are:
>
> * wikosm
> * wikidosm
>
> Suggestions?  Votes?  The service combines Wikidata and OpenStreetMap
> databases, and uses SPARQL (query language) to search it, so might be
> good to reflect that in the name.
>
> https://wiki.openstreetmap.org/wiki/Wikidata%2BOSM_SPARQL_query_service
>
> P.S.  I know this is the hardest problem after off-by-one and caching...



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Disputed border between Greece and Turkey near Imia/Kardak in the Aegean Sea

[Florian Schäfer]

Am 31.03.2017 um 07:09 schrieb Marc Gemis:
> On Fri, Mar 31, 2017 at 6:39 AM, David Marchal  > wrote:
> >/If I correctly remember, in such cases, both point of views should be
> used; />/in this case, two boundary segments should be dragged: one including 
> the />/islets with Greece, and the other one including them with Turkey. /
> The rule is that border in OSM is where you have to show your passport
> to the customs. Or where the barbed wire stands, or  whatever on the
> ground fact indicates the presence of a border. The French-Italian
> border which overlaps on the Mont-Blanc is not the preferred way
> AFAIK.
>
> m.

Probably neither of your criteria fits for this case. These two islands
are uninhabited according to Wikipedia (by the way, they are together
only 4 ha in size, the same size as a 200 meter × 200 meter square), so
there won't be customs on there. And I doubt that there is barbed wire
on there either, because in either case the border would run through the
sea around the island on one side or the other.

/Florian


signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Disputed border between Greece and Turkey near Imia/Kardak in the Aegean Sea (was: Re: [Geocoding] Boundries of Kardak Islands)

[Florian Schäfer]

Dear İlhami Özer,

These borders are disputed and the island is claimed by both Greece and
Turkey.

There was a recent incident near the island in January: "A Turkish navy
missile boat accompanied with two special-forces speedboats entered the
area around the islets on 29 January 2017. According to the statement
issued by the Defence Ministry of Greece, they were blocked and warned
by Greek coast guard vessels and withdrew from the area after about
seven minutes. The Turkish armed forces denied that the ships were
blocked but did not otherwise deny the incident; they stated that the
mission was a part of an inspection of the Aksaz Naval Base by chief of
General Staff Hulusi Akar, who was on board at the time." (Source:
Wikipedia article about the island
)

You (I assume it's you, because of the similarity of your username
 and your real name and the
proximity of time to your e-mail to the list) now changed the borders to
reflect your point of view in this changeset yesterday:
https://openstreetmap.org/changeset/47194531 .

I'm not an expert on borders and how disputed borders are handled in
OSM, so I forward this to the talk-list, because this probably needs
more discussion.

Regards,
Florian

Am 27.03.2017 um 10:36 schrieb ilhami özer:
> Dear Openstreetmap valuable workers,
>
> This situation is really important for us. The two islands are within
> bounderies of Turkey Republic. As you can see on the image which we
> sent attachment these two islands out of boundries of Turkey on your
> tile images. We did necessary changes on feature parts. Please can you
> make these changes on your basemap.
>
> Kindly request.
>
> -- 
> İlhami ÖZER 


signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[Talk-de] GMaps-Import in Algerien?

[Florian Schäfer]

Guten Abend,
beim Ausprobieren des neuen Features von TagInfo (eigentlich wollte ich
die _highway_ Tags entfernen) sind mir einige Straßen in Algerien rund
um die Stadt Muaskar mit ungewöhnlichen Tags aufgefallen.

Hier ein Beispiel: http://osm.org/way/190027214

Die Tags, die ich meine, beginnen und enden alle mit einem Unterstrich.
Zum Beispiel: _id_, _ref_, _lanes_, _maxspeed_, _highway_, _GM_TYPE_
oder _GM_LAYER_. http://overpass-turbo.eu/s/82a sollte zumindest die
meisten Elemente, die ich meine, enthalten.

Da sie oft die entsprechenden Tags ohne Unterstriche duplizieren bzw.
keinen Mehrwert liefern, wollte ich sie zunächst einfach entfernen. Aber
inzwischen glaube ich, dass diese Tags vermutlich von Google Maps
importiert wurden. Die Unterstriche wurden vermutlich verwendet um
bestehende Tags nicht zu überschreiben. Und die Abkürzung GM hat mich
darauf gebracht, dass die Daten von Google Maps stammen könnten. Die
Änderungssatz-Kommentare sind hier zur Einordnung leider gar nicht
hilfreich, da sie meist gar nichts enthalten.

Allerdings scheinen die Geometrien nicht importiert worden zu sein. Ich
habe mal verschiedene dieser Straßen per MapCompare mit GMaps verglichen
und die Verläufe sind unterschiedlich. Auch bei Ways, die seit Version 1
nicht bearbeitet wurden.

Den User, der soweit ich das gesehen habe die meisten dieser Ways
hinzugefügt hat, habe ich schon per OSM-Nachricht angeschrieben.

Was ich nun gerne wissen würde, wäre:
Kann jemand von euch mit größerer Gewissheit sagen, ob die Tags von
GMaps stammen?
Was wären die nächsten Schritte, falls es sich wirklich um nicht
ODbL-konforme Eintragungen handeln sollte? Müsste die DWG informiert
werden, oder reicht es die entsprechenden Tags zu entfernen?
Ist es in Ordnung, wenn ich jetzt schon zumindest die redundanten Tags
entferne? Oder ist es ratsam zu warten, bis klar ist, ob die Tags
unerlaubt importiert wurden (um z.B.Revertieren/Redaktion zu vereinfachen)?

Viele Grüße und schönen Abend,
Florian



signature.asc
Description: OpenPGP digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] JOSM Entfernung in Fuß?

[Florian Schäfer]

Klicke mal auf die Anzeige drauf, dann ändert sich zumindest bei mir die
Einheit.

Viele Grüße,
Florian

Am 28.12.2014 um 21:39 schrieb Johannes:
 Hallo,

 ich wundere mich schon länger warum bei mir in JOSM die einfache
 Entfernungsanzeige es Ways unten in der Statusleiste zu große Werte und
 als Einheit mit zwei leere Kästchen. Habe das mal an einer mir bekannte
 Garage gemessen, sieht so aus als ob die Größe in Fuß angegeben sein.

 Wo kann man wieder Meter einstellen?
 Gruß Johannes



signature.asc
Description: OpenPGP digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Fehlerhafte restriction relation - wo melden?

[Florian Schäfer]

Das scheint ein Fehler in OSRM zu sein. Denn die
Abbiegebeschränkungsrelationen sehen für mich in Ordnung aus.
Vielleicht stolpert OSRM ja über die Relation
http://www.osm.org/relation/2812589 , bei der die Mitglieder von hinten
nach vorne sortiert sind (to, via, from) statt wie meistens (from, via, to).
Das Problem scheint auch schon gemeldet zu sein:
https://github.com/Project-OSRM/osrm-backend/issues/1286

Zu Deiner Frage bzgl. JOSM. Du kannst versuchen, die Relation in JOSM
auszuwählen und dann Strg+H (H für „history“) drücken, dann wir
normalerweise die Versionsgeschichte angezeigt. Ich weiß allerdings
nicht, ob das in Deiner JOSM-Version schon drin ist.

Viele Grüße,
floscher

Am 23.11.2014 um 14:22 schrieb Butrus Damaskus:
 Hallo!

 Ich bin auf ein routing Fehler in OSRM gestoßen: siehe http://osrm.at/a8E

 Habe versucht im JOSM nachzuforschen, wer dies verursacht hat, leider kann
 mir das (meine Version von) JOSM nicht sagen, da es an den restriction
 relation liegt - ich kann aber weder die Relationsnummer noch den user
 sehen. Hat jemand einen Tip, wie ich denjenigen finde, der diese Relation
 zugefügt hat?

 (Ich nutze die JOSM, die mit Debian Wheezy mitgeliefert ist und würde
 ungern unsystematich per Hand irgendwelche experimentelle Version
 stattdessen installieren...)

 MFG



signature.asc
Description: OpenPGP digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Schwarzwald bei Ludwigsburg ?

[Florian Schäfer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



Am 17.11.2014 um 11:04 schrieb Martin Koppenhoefer:
 Am 16. November 2014 23:45 schrieb Florian Schäfer
 flor...@schaeferban.de:
 
 Ich habe mal „Schworzwald“ statt „Schwarzwold“ probiert. Das
 Label taucht immernoch bei Ludwigsburg auf und lautet nun
 „Schworzwald“ ;-).
 
 
 
 
 bitte nicht mit den live Daten testen. Das Problem liegt evtl. bei 
 osm2pgsql beim Einspielen von diffs und Löschen / Ändern von MP
 Relationen *), hat also ziemlich sicher nichts mit dem Carto
 Mapnikrenderingstil zu tun.
Ich wollte nur zeigen, dass es das Label der Relation 1395820 ist.
Dazu schien mir das (geringfügige) Ändern des Labels in den Live-Daten
das einfachste Mittel. Habe die Änderung auch inzwischen reverted.

Dass es ein Problem mit der Mapnik-Software oder osm2pgsql ist, habe
ich auch vermutet. Da ich aber nicht wusste, in welcher Software der
Fehler am wahrscheinlichsten liegt, habe ich mich mal an osm-carto
gewendet, da ich mir von dort einen Hinweis auf die Ursache erhofft hatte.
 
 Gruß, Martin
 
 
 *) das vermutet zumindest Paul Norman so auf osm-dev und verweist
 auf diesen, mittlerweile gefixten Bug: 
 https://github.com/openstreetmap/osm2pgsql/issues/67 Auch wenn es
 nicht dieser Bug sondern ein anderer ist, in den gegenwärtigen 
 Daten und beim Renderstil ist das Problem ziemlich sicher nicht
 verortet.
Danke für den Hinweis, dort lese ich normalerweise nicht mit, habe
aber inzwischen auf den Thread dort geantwortet und unter anderem
angemerkt, dass ich nicht glaube, dass der genannte Fehler für den
Schwarzwald bei Ludwigsburg verantwortlich ist.

Viele Grüße,
Florian
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJUafIzAAoJEL4C5+PUNkMtCAcQAKAQT4YFx5S18rfBxe2IfRlW
Z2D6vwronBNH936n9tdHbnQsv4tN3LUmcK+Jt2BYiewuEkZ7fm1Zfqn1hlCSd1Kj
6aZhhHGjA4Tjx2Xb3xtKLiMJsliqUQNi/wmChKT93ezDizFGBRY5NrrLDwRLWTO1
+c38DyXWonx49PMW6KCjSZBTZUG+5eYDzVY8RM5fwE1IgGS1YjZs7ARPKYHi9lHS
OivtEQ1dpZ38Ao5yhggbGewr/0KriiRcgL7f7gJuhfqIjB5CM21W5w3d31Uvz2Pz
r+Z+ROrZFXrtzyHSz3+MjWLfi/lCQ35dyh3dRlLiXywgQE0QAhK/fNEdiP8P6Fys
0F7MBx6MDo0pRGZ3BgSttDlZBMM3RouY+LDo8vvexp2pGB/yMpfBMeekeHtlh4ru
RwnkbcfKEk+VeHLWdBJExrlOzezotD8ICbv8rwMS6mLLwHsSpzKf2KQFeFtcnCeh
aACuBvZyC/pVb0+7PqQPDO29OwraRN/Z7Xw172pm2Yk27vPceosW6oJb3i/a7+Qi
3tIomSm4p38wpAD6ZGZoz6kOXDg5yQ2j+RT2Qv4OxpI0Hamjl3Xc+FaF9oSJwqmj
iSNhMkGdaB5McIrIyNoAcJbl12tvzw8wyH8A+S/REN97eAeBWuX5BYYOEQ9AQc9P
CqqnRKSt5uhGQ3asxOdA
=oEem
-END PGP SIGNATURE-

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

Re: [Talk-de] Schwarzwald bei Ludwigsburg ?

[Florian Schäfer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hallo Loth,
dazu ist mir gerade die Relation
http://www.openstreetmap.org/relation/1395820 aufgefallen. Und zwar
wird im Standardstil auf osm.org das Label nicht gerendert (zumindest
nicht innerhalb des outer-polygons).

Ich habe den Stil auch lokal aufgesetzt, wo das Label der Relation im
Zentrum des Multipolygons gerendert wird. Dafür wird dort unter
Ludwigsburg nicht „Schwarzwald“ gerendert. Allerdings sind die lokalen
Daten nicht mehr die aktuellsten, sodass das auch andere Gründe haben
kann.

Das Ganze spricht aus meiner Sicht sehr dafür, dass die spezielle
Relation „schuld“ ist am Schwarzwald in Ludwigsburg.

Viele Grüße,
Florian

Am 15.11.2014 um 19:11 schrieb Lothar Beck:
 Entschuldigung, ich bin da nicht so bewandert im Forum. Und auch
 nicht der Profi in Overpass. Ich bin nur ein normaler Mapper aus
 der Gegend von Ludwigsburg den es stört dass wie unten erwähnt auf
 Zoomstufe 11 Schwarzwald unter Ludwigsburg gerendert wird. Das
 passt da nicht hin, der Schwarzwald liegt ja ca. 100 km 
 südwestlich. Auf Zoomstufe 10 steht dann nur noch Schwarzwald
 dort. Im deutschen Kartenstil gibt es kein Schwarzwald unter
 Ludwigsburg. Ich hab das tile dann mit /dirty auch mal zum
 neurendern angestossen, das hat aber auch nichts gebracht, denn mit
 /status habe ich gesehen dass es aktuell ist.
 
 Direkt in Ludwigsburg finde ich da nichts mit Schwarzwald und ein
 größeres Gebiet läßt mich JOSM nicht laden. Deshalb der Versuch mit
 der overpass turbo Abfrage, wo ich aber auch keinen Erfolg hatte
 (Ich fand zwar viele Schwarzwald, aber eben nur da wo sie
 hingehören nämlich im Schwarzwald und nicht bei Ludwigsburg) Ich
 vermute da gibt es irgendwo in der Datenbank eine große Relation
 oder Grenze oder was auch immer mit dem Namen Schwarzwald, was dann
 dazu führt dass der Name dort bei Ludwigsburg gerendert wird. Ich
 wäre glücklich wenn mir einer die ID und den Typ des Elementes
 dazu in der Datenbank findet. Dann kann ich weitersehen welchen
 Sinn das hat oder ob man das ändert / löscht.
 
 Gruss Loth
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJUaRH3AAoJEL4C5+PUNkMt6TIP/Rvk7aC57KRezKjfInIwD8qJ
BpD7BcG9uWh7UgFXw18cfEofDWbnp/Jin3TP/WxkaY9aec1NTzEdMmFUn54e17RW
2LkTu9ZUySK7x4kLMVavVARSeB7Krh45msUrDCvOCrm4L2O9K5u9w5JOAU4FD+i3
rfkflkEHqqt5EB/qN9PiYkJEIDXbnLtjziypHbUEPeuDv7WQZJJGNin21lq1DSUf
XdMcko+CRUwLwM/8NxVC4+6hzXX4wutk9tTavtIKUHABioej+Xa0vwhqSvrRAwG/
fs80ja0rezFSEvvRisEX5iC3DiOwaz2bexqplZEPBqlLpfQfbadHcUoAQiWtOEQA
UN3zO7QuHWOyiRBm7rLaKFgQxRM3njtninlcuTEiee3osFb3Y1bqPWjqwh8aDESP
qivDY4hPJqv81HwCcQbFoj74pbl8iAaSDVpDa1Eu4WBG7BmFRbEV1yTDUL1aDt0V
iFohmkjSA58qweNzzZbwfQSe66VpjoytTFtxDP1oi3P9Z6CQ97ZdMNymMrDLTQNF
/hPK28aOlY0iRM0hvVYuvloNNb6CtCIP+o4vij1feIFR7jB65EoTi4qL4sdN2IsQ
OJ18T5guR3lCcbx/CEkSLvjUdlx3Fu8S6ov2MSeby6i5L+v2IyG0LfS8j1vECVur
8BI9OyesNmv/dqjGvk9B
=xoZ7
-END PGP SIGNATURE-

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

Re: [Talk-de] Schwarzwald bei Ludwigsburg ?

[Florian Schäfer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



Am 16.11.2014 um 23:39 schrieb Lothar Beck:
 
 
 Hallo Alle,
 
 zuerst vielen Dank an alle die mithelfen diesen Fehler zu finden. 
 Ich habe dabei viel über overpass turbo und deren Möglichkeiten
 gelernt. Aber das hilft auch wenig zum Finden wenn der Renderer das
 Label vermutlich falsch plaziert.
 
 So ist das sicher den Versuch wert den Namen der verdächtigen
 Relation auf Schwarzwold zu ändern um zu sehen ob und wo der
 auftaucht.

Ich habe mal „Schworzwald“ statt „Schwarzwold“ probiert. Das Label
taucht immernoch bei Ludwigsburg auf und lautet nun „Schworzwald“ ;-).

http://tile.openstreetmap.org/11/1076/704.png


 
 
 Dank und Gruss Lothar
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJUaSkSAAoJEL4C5+PUNkMt6L8QANNI2TN6+eb0+BQVYz15ArJS
OZQ9OySUBcNMX/K7Yqb6OgctggCM9RHsZx1K8txA6sLPDOJSbQmCHW5jPSuycobH
jh5rvObP5lASwdXuXeX1b8XRhDVV+6NLnlnoTv0QtujbpWr4e4O5LZsmlkNAtASH
TKbx0CWqYGBR6kpUFGPXEkMuAU2EZPoAkaLHl2Z/ydLSVIyNoGqP0I7/JMDq4bRh
cbgdnzyvPJ7+AUHQE/s61qxmoxq8g8xsSDb/ud8qYTMuhRwdjPHLI0fSlkKOcmvB
vdL3E5YZh5g0Gb1m/cHQ+NqhJFz14TF4uFmIBFoJViyS4v7cipKcU78xpt9IgBju
Z/V14JBLOkzZM5zNjaaJ4FLrYote3QmHpKmMA4I2yGqIU1DTP9Uwu51GRKx1ukTT
hS1vY8mdYQnqE+IsfO/VfPc5VPosK6G7i9zyoctvEUjq/4IQMEe2dMvZll8L9ejk
gE9ivSApWaZ6k++Re0l18bpwF6L+Eu5MsBKfxmPiRisv9mH3RhhuiD453+/SdvAj
RjZylyNYz88rEkM5EJ9upWdal4LDmxEaj2KqRppq7NFGQSy57MH2l0Q3F9vtUxsg
ekgQfcwGk1T2Wn1YysZm/TbXKgWq5ppXLv32HFSiXRXHHSYfXAv1LyYinocUI0Am
lDX3gk21cFwIOvQLYL4k
=bz5R
-END PGP SIGNATURE-

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

Re: [Talk-de] Schworzwald bei Ludwigsburg ?

[Florian Schäfer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Nachtrag:
Habe gerade den osm-carto-Entwicklern auf GitHub den Fehler gemeldet
[1]. Vielleicht weiß dort jemand, wie der Fehler zustandekommt und
vielleicht sogar, wie man ihn behebt.

[1]: https://github.com/gravitystorm/openstreetmap-carto/issues/1133

Am 16.11.2014 um 23:45 schrieb Florian Schäfer:
 
 
 Am 16.11.2014 um 23:39 schrieb Lothar Beck:
 
 
 Hallo Alle,
 
 zuerst vielen Dank an alle die mithelfen diesen Fehler zu finden.
  Ich habe dabei viel über overpass turbo und deren Möglichkeiten 
 gelernt. Aber das hilft auch wenig zum Finden wenn der Renderer
 das Label vermutlich falsch plaziert.
 
 So ist das sicher den Versuch wert den Namen der verdächtigen 
 Relation auf Schwarzwold zu ändern um zu sehen ob und wo der 
 auftaucht.
 
 Ich habe mal „Schworzwald“ statt „Schwarzwold“ probiert. Das Label 
 taucht immernoch bei Ludwigsburg auf und lautet nun „Schworzwald“
 ;-).
 
 http://tile.openstreetmap.org/11/1076/704.png
 
 
 Dank und Gruss Lothar
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJUaTCeAAoJEL4C5+PUNkMtXP4P/i6G0jRv/LVKqvXeUNKJInc9
F5tsBDFUagxRQaJLuHb9QCnFXg8LaVf2whl3u4DxjgMLbUhZSQLy3REVSh91IZL1
VIU4dQOdGRbSFrtUAwAM9wcy5txjqSo0L+AVPCNZecT3CHTiu2vfcCqWtGosyVVf
LWh8FMZYuvQicvowZ3exZxNgmxqFkfqwjMFK74UXgVb6+c1Eq07vuAD7XZM/Hkt6
Gs4vKAXoh4pk4erxGsLMLIDGUdjYvN+nEXLbZJJspanNzMG2KQOx2mgObJj7Il/D
GyAIaW1bYB1kMxd1MRm7U6ifMXM92lRktbA85tCRvpPd5aUXVa6IjANdHZ2S13Mz
WCxIDFOow25c9Xq+xvKhaRfrd0ff0okEEbG1pf1415FO0KMjDGKRgDe3EDY4WeeM
Kh2m1B2T6F6pOKHBqCizgmSkGAXhU8CZFICWNeQaYGXgHLfoVshB8FWfEHXoclFK
wiCu131RPsTf4trzjupvjDsM5L5jAiwJDFST1+GPLHP1gM7ONAHfVg4pMJnuTAAe
j9TiT1hzhBcreKrGBPYYkZIT+ppg/oRjTRuN5Ddl+68moYqcJEoxp90paK+R59bY
X5PsCghlWhhPLlPEVUzZfMvQ8Ta/O9yoW3GUNqof/mX0ADPYo6ZDLztekLJDpcxG
tXSY5pcsILnPxm/LGr6I
=sZtJ
-END PGP SIGNATURE-

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

Re: [Talk-de] Berlin Stadtbaumkampagne

[Florian Schäfer]

Am 15.08.2014 um 08:03 schrieb Holger Jeromin:
 Johannes wrote on 15.08.2014 07:30:
 Bei Bäumen bietet sich meiner Meinung nach besonders ein Wikidata-Tag an.
 wikidata=Q161364

 https://www.wikidata.org/wiki/Q161364?uselang=de
 Aber bitte nicht als wikidata= tag, da der Wikidata-Eintrag nicht über
 diesen spezifischen Baum geht.

 species:wikidata=
 oder so :-)

+1

Obwohl die wikidata-Tags mit Präfix scheinbar nicht sehr beliebt sind.
Zumindest hatte ich diesen Eindruck, als ich vorgeschlagen habe, diese
auf osm.org mit WikiData zu verlinken [1].

Ich fände es hier allerdings einen weiteren guten Anwendungsfall für die
Verknüpfung von WikiData und OSM, denn fürs Bäume bestimmen ist WikiData
viel besser geeignet, als OSM.

Übrigens: Falls ich mir ein Taggingschema aussuchen könnte, würde ich
dafür nicht species:wikidata oder Ähnliches verwenden, sondern zum
Beispiel P31:wikidata=Q161364, was dann aussagen würde: „ist ein“ (P31)
„Rot-Ahorn“ (Q161364). Wenn schon WikiData, dann richtig…
Aber mit species:wikidata=* wäre ich auch schon sehr zufrieden.

Gruß,
floscher

[1]: https://github.com/openstreetmap/openstreetmap-website/pull/788



signature.asc
Description: OpenPGP digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Markierungen auf Sportplätzen

[Florian Schäfer]

Am 05.06.2014 15:44, schrieb Martin Koppenhoefer:
 Am 5. Juni 2014 11:00 schrieb Sven Geggus li...@fuchsschwanzdomain.de:

 Mir ist nicht klar, was marked genau bedeuten soll, aber es ist als
 Tag-Name auf jeden Fall viel zu generisch. So wie class und type und
 so. Wer oder was wird da markiert?
 Ähm, das Spielfeld natürlich. Es gibt markierte und nicht markierte Felder.

 Die Google Bildersuche findet jedenfalls bei soccer field marking genau
 das Richtige.



 aber bei marked wohl eher nicht ;-)
 ich fände den tag soccer_field_marking gar nicht so schlecht
 (vorausgesetzt, man wollte das überhaupt taggen), das könnte man
 kombinieren mit anderen Sportartenmarkierungen, wie es z.B. auf
 Schulsportplätzen meistens zu finden ist. sport=multi, pitch_marking=yes
 würde einen im anderen Fall nämlich kaum weiterbringen.

 Gruß Martin
Außerdem gibt es auch noch Spielfelder mit Markierungen für mehrere
Sportarten (siehe Bsp. [1]).
Wie wäre es z.B. mit field_marking=soccer und in dem Beispiel dann
field_marking=soccer;volleyball;basketball
Aber bitte keine Diskussion über Semikola vom Zaun brechen ;-).

Da fällt mir gerade ein: Insbesondere bei Mehrfachnutzung wäre die Farbe
der Markierung nicht schlecht, wie wäre es dann mit folgendem:
field_marking:basketball=#00

Gruß,
Florian


[1]: http://www.stadionwelt-business.de/images/news/1306232399.jpg



signature.asc
Description: OpenPGP digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Meinungsbild noexit auf der Tagging-Liste

[Florian Schäfer]

Am 06.04.2014 04:09, schrieb fly:

On 03.04.2014 21:43, Florian Schäfer wrote:


OK, dann haben wir das denke ich fürs erste ausdiskutiert.
Übrigens geht die Diskussion gerade auf der Tagging-ML weiter ;-) (ich
war's diesmal nicht).

Da es auf dieser Liste doch einigen Klärungsbedarf gab, dachte ich, es
wäre gut diese Diskussion auch auf Englisch zu führen.

Immerhin würde die englische Wiki-Seite jetzt auch angepasst sowie
einige anderssprachige Seiten.

cu fly


Ja, klar. Es war nicht als Vorwurf gegen dich gedacht.
Scheinbar gibt es ja auf der englischen Mailingliste denselben 
Klärungsbedarf, wie auf Talk-DE, wenn nicht gar noch mehr (manche wollen 
ja dort z.B. noexit=yes auf ways und nicht auf Knoten).
Von daher bin ich Dir dankbar, dass Du das Thema dort nochmal 
angesprochen hast.


Ich bin aber noch am Überlegen, wie man die Inkonsistenzen zwischen dem 
Ergebnis auf Talk-DE und dem Ergebnis auf Tagging auflöst. Auf der 
englischen Seite wurde ja inzwischen auch schon editiert, um die 
Diskussionsergebnisse im Wiki festzuhalten.


Viele Grüße,
Florian

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

Re: [Talk-de] Meinungsbild noexit

[Florian Schäfer]

Hallo Stephan,

Am 03.04.2014 00:41, schrieb Stephan Wolff:

Am 30.03.2014 13:57, schrieb Florian Schäfer:
 Hallo Liste,
 ich würde gerne mal bei euch ein kleines Meinungsbild einholen über
 die Verwendung des Keys noexit

 In den folgenden Situationen habe ich beispielsweise schon
 noexit=yes-Tags gesehen:
 *A*: Strikte Sackgassen auf öffentlichen Straßen (Zeichen 357
 https://commons.wikimedia.org/wiki/File:Zeichen_357.svg)

Ich finde noexit allenfalls in diesem Fall sinnvoll. Private Wege zu 
Haustüren oder Garagen, die dort abzweigen, würde ich ignorieren.
Ja, solange der Weg zu Türen/Toren/... führt stimme ich Dir zu. Wenn ein 
Privatweg (oder Waldweg) aber einfach so aufhört, kann meiner Meinung 
nach auch dort noexit=yes sinnvoll sein.
Laut deutschen Wiki ist noexit nur für Punkte definiert, in der 
englischen Version auch für Wege, ohne dass dies genauer beschrieben 
ist. Würde man Wendeschleifen in Sackgassen mit noexit=yes versehen?
Sobald die Wendeschleife wirklich als Schleife gemappt ist, also nicht 
als Node mit highway=turning_circle oder so, würde ich noexit=yes nicht 
mehr setzen. Weder auf den Way der Schleife, noch auf einen der Nodes. 
Denn der Weg geht ja quasi weiter, nur halt auf dem selben Weg, den Du 
gekommen bist.
Sollte man alle Werte außer yes und no entfernen oder ist eine 
Erweiterung wie noexit=motor_vehicle (169 Verwendungen) sinnvoll?
Ich finde alle Werte außer yes nicht sinnvoll. no alleine schon von 
der doppelten Verneinung her, da ist fixme=continue besser.
Und wenn sich jemand die Mühe macht, das Ende eines Wegs als 
noexit=motor_vehicle zu kennzeichnen, soll er doch bitte gleich den 
weiterführenden Weg einzeichnen und mit motor_vehicle=no (und weiteren 
passenden access-Tags) versehen. Und falls er den Verlauf nicht kennt, 
kann er ja den Anfang davon einzeichnen (ein paar Meter lang) und den 
mit fixme=continue und motor_vehicle=no (und weiteren passenden 
access-Tags) versehen.


Heißt also:
Wenn ich noexit=no begegnen würde, würde ich nach Möglichkeit den 
fehlenden Weg einzeichnen, oder es durch das geläufigere und 
eingängigere fixme=continue ersetzen. Vorausgesetzt natürlich, der 
weiterführende Weg ist noch nicht eingezeichnet, dann kann es einfach so 
entfernt werden.
Die anderen noexit-Werte würde ich wie eben beschrieben durch den 
weiterführenden Weg (oder zumindest den Anfang davon) plus access-Tags 
ersetzen.


Viele Grüße,
Florian

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

[Talk-de] Überarbeitung der Wikiseite zu noexit=yes

[Florian Schäfer]

Hallo zusammen,
wie bereits angekündigt, habe ich mal die Wikiseite DE:Key:noexit [1] 
nach den Erkenntnissen aus der Diskussion hier überarbeitet.
Wie schon bei der obigen Zusammenfassung soll dies natürlich nur ein 
Vorschlag sein. Kritik und Anregungen dazu sind selbstverständlich sehr 
willkommen.
Falls ihr etwas aus der bisherigen Version [2] vermisst oder mit 
irgendetwas in der neuen Seite nicht zufrieden seid, ändert es gerne 
selber indem ihr die Wikiseite bearbeitet, oder antwortet auf diese Mail.


Viele Grüße,
Florian

[1]: https://wiki.openstreetmap.org/wiki/DE:Key:noexit
[2]: 
https://wiki.openstreetmap.org/w/index.php?title=DE:Key:noexitoldid=990619


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

Re: [Talk-de] Meinungsbild noexit (Versuch einer Zusammenfassung)

[Florian Schäfer]

Hallo Stefan, hallo Falk,

Am 03.04.2014 20:16, schrieb Falk Zscheile:

Am 3. April 2014 00:38 schrieb Stephan Wolff s.wo...@web.de:

Am 01.04.2014 10:14, schrieb Falk Zscheile:

Ich bin dazu übergegangen im Verkehrsbereich (zusätzlich) zu den
etablierten Tags von OSM auch explitzit das Straßenschild zu erfassen,
um der möglichen Doppelbedeutung von tags entgegenzuwirken.

Damit führst du doch eine Doppelbedeutung erst ein.

Nein, entweder ist es redundant oder klarstellend. Aber jedenfalls
keine Förderung von Doppelbedeutungen, denn im Gegensatz zu noexit=yes
hat access:traffic_sign=DE:397 einen festen Bedeutungsinhalt, den du
in der StVO nachschlagen kannst.
Ich sehe im Tagging ebenfalls keine Doppelbedeutung. Denn 
traffic_sign=DE:397 sagt aus: Hier steht ein Schild und noexit=yes 
sagt aus: Diese Straße endet an diesem Punkt für alle Verkehrsteilnehmer.
Es sollte zwar im Idealfall so sein, dass das Straßenschild das Tag 
noexit=yes impliziert, in der Realität sieht das aber anders aus.
Außerdem würde ich traffic_sign=DE:397 nur da setzen, wo auch in der 
Realität ein Schild steht. Und zwar auch genau an die Stelle, wo es 
steht, also an in der Regel an den Anfang der Straße.


Das Schilder-Tagging dient also dem Erfassen, wie es ausgeschildert ist. 
noexit hingegen bildet die faktische Realität ab, also ob die Straße 
tatsächlich eine Sackgasse ist.

Im Falle eines Verkehrsschildes würde ich also mappen: noexit=yes,
access:traffic_sign=DE:397

Wenn man das Schild erfassen will (ich finde das eher unnötig), dann wäre
mit traffic_sign=DE:397 der Inhalt vollständig beschrieben.

Und was machst du, wenn auf der Straße gleichzeitig noch eine
Geschwindigkeitsbegrenzung und ein Halteverbot stehen. Ich habe da
eine Lösung: access:traffic_sign=DE:value und
parking:traffic_sign=DE:value  und maxspeed:traffic_sign=DE:value
@Stefan: Nein, siehe oben. Das Schild beschreibt, wie ausgeschildert 
ist, noexit, wie die Realität aussieht.


@Falk: Siehe oben, ich würde Verkehrsschilder immer dort mappen, wo sie 
stehen (nicht am Ende der Sackgasse).
Zum Schildertagging würde ich sagen, ich tagge 
traffic_sign=DE:value1;DE:value2;DE:value3 oder alternativ 3 Nodes nahe 
beieinander. Denn die Funktion des Schilds leitet sich aus dem Value ab.
Das würde auch Missverständnissen vorbeugen. Vielleicht gibt es 
Schilder, die mancher in parking, ein anderer in access einordnen würde.



noexit=yes beschreibt, dass an diesem Punkt ein Weg blind endet, und ist
für das Schild nicht nur überflüssig sondern falsch.

Aha?  Übrigens heißt access nicht Zugangsbeschränkung sondern Zugang
und darüber trifft traffic_sign=DE:397 sehr wohl eine Aussage.
@Falk: Es könnte sein, dass Stefan meint, dass das Schild neben dem Weg 
am Anfang der Sackgasse steht und dort kein noexit=yes hinkommt.


Gruß,
Florian

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

Re: [Talk-de] Meinungsbild noexit (Versuch einer Zusammenfassung)

[Florian Schäfer]

Am 03.04.2014 20:29, schrieb Falk Zscheile:

Am 3. April 2014 15:20 schrieb Martin Koppenhoefer dieterdre...@gmail.com:

Am 3. April 2014 00:38 schrieb Stephan Wolff s.wo...@web.de:

+1, ich würde wenn ich Schilder erfassen würde (was ich derzeit nur für
Ortseingangsschilder und Geschwindigkeitsbegrenzungen, und Höhen-, Breiten-
und Gewichtsbegr. mache), das nicht an den Weg taggen, sondern an einen
node, eben so, wie man es auch antrifft. Dabei setze ich das Schild in
Fahrtrichtung rechts des Wegs in einem geringen Abstand, so dass die
Richtung normalerweise klar wird (bisher noch keine Ausnahme angetroffen,
gibt es aber vielleicht, kann man i.d.R. durch Optimieren der Abstände
regeln). Wenn man das Schild an den way setzt, dann führt das hinterher zu
ähnlichen Folgefehlern (durch Splitten des ways, Verschieben der Endnodes
etc.) wie bei den übrigen tags auch.

\begin{Ironie}So wie wir die Straßennamensschilder auch dort eintragen
wo sie stehen, aber keinesfalls den Namen an der Straße selbst, denn
da steht ja kein Namen auf den Asphalt gemalt?\end{Ironie}

Die Information gehört dorthin, wo sie sinnvoll ist und dass ist am
highway=value! So machen wir das bei oneway, maxspeed, maxweight/hight
etc. Also warum nicht auch bei allen anderen Verkehrsschildern, die
sich auf ein Wegstück und nicht auf einen Punkt (Fußgängerüberweg,
Ampel) beziehen?
Der Unterschied ist, dass an den Weg die Information kommt, was das 
Schild aussagt.

Beim Straßenschild der Straßenname, bei DE:274:30 ist es maxspeed=30/
/Die Information, welches Schild dort steht und wo es steht, würde ich 
an die genaue Position des Schildes (neben der Straße) taggen, _wenn_ 
ich Schilder mappen würde. Und die Auswirkungen des Schildes (maxspeed, 
access, ...) auf den Weg, um die Ausdehnung des Gültigkeitsbereichs 
deutlich zu machen und die Auswertung zu vereinfachen. Ausnahme 
natürlich noexit=yes, wo es der Endnode statt dem Weg ist.

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

Re: [Talk-de] Meinungsbild noexit (Versuch einer Zusammenfassung)

[Florian Schäfer]

Am 03.04.2014 20:52, schrieb Falk Zscheile:

Wie gesagt, bei Straßennamen handhaben wir das anders und ich halte
das auch bei anderen (hier Verkehrs-) Schildern für sinnvoll. Ich
erinnere mich noch gut an die Klagen, von Leuten, die versucht haben
die Bedeutung von als Punkt eingetragenen Schildern auszuwerten. Das
hat bei Stoppschildern nicht funktioniert, das funktioniert bei
Ortseingangsschildern nicht ... Deshalb will ich nicht ein in meinen
Augen falsches Konzept übernehmen.
Aber Du möchtest doch wie ich das verstanden habe auch punktförmige 
Schilder mappen, oder?
Zum Thema mit den Straßennamen, siehe meine andere Mail zum Unterschied 
zwischen Aussage eines Schilds und Schild.

Zum Schildertagging würde ich sagen, ich tagge
traffic_sign=DE:value1;DE:value2;DE:value3 oder alternativ 3 Nodes nahe
beieinander. Denn die Funktion des Schilds leitet sich aus dem Value ab.
Das würde auch Missverständnissen vorbeugen. Vielleicht gibt es Schilder,
die mancher in parking, ein anderer in access einordnen würde.

Was genauso wenig ausgewertet wird, wie mein System.

Was weder ein Argument für das eine, noch für das andere System ist.

Mit Aufzählungen
im value-Bereich tut man sich meines Wissens auch sehr schwer. Kennst
du eine Anwendung, die das mittlerweile auswertet?
Ich habe vor einiger Zeit mal eine gebaut (zwar nicht im Zusammenhang 
mit Straßenschildern, sondern mit POIs) ;-P.

Und so schwer wäre das auch nicht umzusetzen.

Ich nehme eine
Kategorisierung vor, indem ich access oder maxspeed dazu nehme. Gerade
bei der zunehmenden Flut von tags an Straßen finde ich das sehr
hilfreich.
Die Kategorisierung ist aber durch den Value für traffic_sign schon 
impliziert. Du hättest dann Probleme mit so etwas wie 
maxspeed:traffic_sign=DE:250
Das würde dann in etwa bedeuten: Die Höchstgeschwindigkeit ist, dass 
hier kein Fahrzeug durchfahren darf./

/
Übrigens, nur um es klarzustellen: Ich bin eigentlich kein Fan vom 
Tagging von Verkehrsschildern. Wenn das aber gemacht wird, dann sollte 
die Art und Weise möglichst einheitlich sein und ein gewisser Konsens 
dazu herrschen, sonst wird es niemals ausgewertet werden.


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

Re: [Talk-de] Meinungsbild noexit (Versuch einer Zusammenfassung)

[Florian Schäfer]

Wenn das aber gemacht wird, dann sollte die Art und
Weise möglichst einheitlich sein und ein gewisser Konsens dazu herrschen,
sonst wird es niemals ausgewertet werden.


Ich nehme die hier vorgebrachten Einwände mit Interesse zur Kenntnis,
auch wenn sie mich im Augenblick nicht überzeugen. Man muss ja auch
mal was ausprobieren und schauen, ob man damit mehr bestehende
OSM-Probleme löst als neue schafft :-)

Viele Grüße
Falk
Klar, probieren geht oft über studieren. Und insbesondere bei OSM hilft 
es oft, einfach mal zu machen, statt eine endlose Diskussion vom Zaun zu 
brechen.


OK, dann haben wir das denke ich fürs erste ausdiskutiert.
Übrigens geht die Diskussion gerade auf der Tagging-ML weiter ;-) (ich 
war's diesmal nicht).


Viele Grüße,
Florian

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

Re: [Talk-de] Meinungsbild noexit (Versuch einer Zusammenfassung)

[Florian Schäfer]

Hi NopMap,

Am 01.04.2014 09:51, schrieb NopMap:

Hi!

Deiner Darstellung muß ich einem wesntlichen Punkt deutlich widersprechen.


Florian Schäfer-2 wrote

Bei C habe ich herausgehört, dass dort das noexit=yes-Tag akzeptiert
ist, aber nicht unbedingt von allen aktiv gesetzt wird.
D und E waren noch nicht so ganz klar, insbesondere hat sich da gezeigt,
dass das entrance-Tag an manchen Stellen präzisiert oder um Hilfstags
ergänzt werden könnte

Allgemein kann man glaube ich sagen, dass dieses Tag (ähnlich dem
fixme=continue oder note=*) ein Tag nur zur Kommunikation unter den
Mappern und zur Signalisierung von false-positives an die QA-Tools ist.

noexit ist *kein internes Tag für Mapper* sondern stellt eine wertvolle
Information dar, deren Anzeige auf Karten im Offroad-Bereich absolut
nützlich ist.
OK, es stimmt, dass es hilfreich sein kann, zu wissen, ob ein Weg 
definitiv nicht weitergeht. Ich würde aber infrage stellen wollen, ob 
die Information Nicht-Mapper so sehr interessiert. Und jemand, der bei 
der Planung von Touren oder ähnlichem auf noexit=yes oder fixme=continue 
verlässt, muss meiner Meinung nach damit rechnen, dass er mal in einer 
Sackgasse landet, wo es angeblich weitergehen sollte, oder einen 
durchgehenden Weg verpasst, weil er dachte, dass dort eine Sackgasse 
wäre. Vor allem im Wald, wo auch gerne mal ein Weg blockiert ist oder 
der Natur überlassen wird oder ein neuer Weg geschaffen wird.
Aber der Punkt, für was genau noexit=yes gebraucht wird und für was 
nicht, ist glaube ich auch untergeordnet. Viel wichtiger ist doch, dass 
wir uns einig sind, dass man an Waldwege, die in Wald und Flur enden, 
noexit=yes dranhängt. Wer das im Endeffekt braucht ist mir ziemlich 
egal, Hauptsache ist, _dass_ es jemand braucht.

Dagegen macht es für mich keinen Sinn, Zufahrten und Zugänge, von denen man
erwartet daß sie ihrer Bestimmung gemäß enden, nochmal mit einem noexit
markiert. Damit gibt man dem Tag zwei Bedeutungen, eine sehr wichtige und
eine zwar nicht falsche, aber überflüssige. Das wäre ungefähr so als wenn
ich eine Treppe noch zusätzlich mit incline=* tagge oder ein Gewässer mit
bicycle=no.
Also der Vergleich mit steps+incline=up und waterway+bicycle=no hinkt, 
wie ich finde. Denn es ist glaube ich nicht die Bestimmung von Zufahrten 
und Zugängen, zu enden. Es gibt zum Beispiel viele Zugangswege zu 
Häusern, die am Haus entlang zur Nachbarstraße führen, oder die einmal 
ums Haus führen, ... Und schon garnicht, wenn ein Weg zu einem 
Hauseingang führt, der ja noch in das Haus hineinführt.
Dagegen kann man beim Waterway annehmen, dass man dort nicht Fahrrad 
fahren kann, deshalb ist dort bicycle=no sinnlos. Obwohl, wenn ich es 
recht überlege, habe ich noch nie von einem Verbot gehört, im Fluss 
Fahrrad zu fahren, daher müsste es eigentlich erlaubt sein, also könnte 
man auch waterway=river und bicycle=yes taggen ;-).
Und bei den Treppen wurde ja schon gesagt, dass man sich da nicht 
einigen konnte, ob highway=steps eher incline=up oder incline=down 
impliziert, weshalb ich auch dazu übergegangen bin, incline immer 
mitzutaggen (bevorzugt incline=up, wo es einfach möglich ist). Und dann 
gibt es ja noch bestimmte Treppen, die incline=down bekommen müssen. 
Vor allem Einbahn-Treppen, die vor allem in Museen o.Ä. vorkommen.


Um nochmal auf noexit zurückzukommen: Ich sehe ehrlich gesagt zwischen 
einer Zufahrt mit noexit und einem Waldweg mit noexit keinen 
Unterschied, außer dass der Wegtyp ein anderer ist.

Es ist richtig, daß ein Router noexit nicht braucht, und solange ich nur
Städte und Straßennetze betrachte, kann ich leicht zu der irrigen Annahme
kommen, es wäre nur intern für Mapper und nicht für Renderer und Nutzer
relevant.

Aber in Wald und Flur ist es eine essentielle Information und
Planungsgrundlage. Es ist ein riesen Unterschied ob ich *weiß *daß ein Weg
endet oder ob ich es nicht weiß und ihn auf gut Glück mal ausprobiere und
hoffe daß er doch weiterführt.

Bitte das nicht ignorieren oder verwässern.
Ja, das war auch nicht meine Absicht. Ich habe die Punkte, die Du 
angesprochen hast nämlich aus den vorangegangenen Mails wirklich nicht 
so stark herausgelesen. Dann ist es ja gut, dass wir noch einmal darüber 
geredet haben.
Das war ja einer der Gründe für meine Zusammenfassung. Mir war schon 
klar, dass die Zusammenfassung natürlich subjektiv ist und es bestimmt 
Leute gibt, die das anders sehen (ist ja auch gut so, ich fände es 
schlimm, wenn es nicht so wäre). Nichtsdestotrotz wollte ich meine 
subjektive Zusammenfassung mal in den Raum werfen, um mal eine Grundlage 
für ein Fazit zu haben, damit die Diskussion auch etwas bringt und nicht 
in einem Jahr wieder hochkocht, weil die Diskussion nicht mit einem 
einigermaßen klaren Konsens endete. Deshalb habe ich es ja auch nur 
Versuch einer Zusammenfassung genannt.


Viele Grüße,
Florian

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

Re: [Talk-de] Meinungsbild noexit

[Florian Schäfer]

Am 30.03.2014 19:14, schrieb Dirk Sohler:

Florian Schäfer schrieb:

Zum einen, ob ihr ihn nützlich findet […]

An Eingangs-Nodes ist er ganz nützlich, wenn der Eingang nicht als
Ausgang genutzt wird, da es einen separaten Ausgang gibt, der
entsprechend der Logik dann mit noentry (oder entsprechendem) versehen
sein sollte :)
Da stellt sich halt die Frage, ob das Tag so herum verstanden wird, also 
dass man nicht aus dem Gebäude heraus kommt, also noexit bezogen auf das 
Gebäude statt auf den Weg.
Meiner Erfahrung soll es in der Regel aussagen, dass der Weg von draußen 
(an Gebäuden ohne Indoormapping) nicht weitergeht, denn es ist ja im 
Wiki auf Wege bezogen definiert.
Letztere Auslegung des Tags finde ich persönlich aber nicht sehr 
sinnvoll, denn in aller Regel gehen Wege noch weiter, wenn sie zu einem 
entrance=* führen (einzige Ausnahmen entrance=exit und entrance=emergency).


Vielleicht könnte man für die Eingänge in nur eine Richtung einen neuen 
entrance-Value erfinden. Es gibt ja schon entrance=exit für Ausgänge, 
die keine Eingänge sind. Analog würde ich entrance=noexit als Eingänge, 
die keine Ausgänge sind, definieren. Das wäre glaube ich eindeutiger.


Gruß,
Florian

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

Re: [Talk-de] Meinungsbild noexit (Versuch einer Zusammenfassung)

[Florian Schäfer]

Am 30.03.2014 13:57, schrieb Florian Schäfer:

A: Strikte Sackgassen auf öffentlichen Straßen (Zeichen 357)
B: Durchlässige Sackgassen auf öffentlichen Straßen (Zeichen 357-50 
oder 357-51)
C: Privatwege auf Privatgrundstücken (z.B. Hausauffahrten), die an dem 
einen Ende unverbunden sind
D: Wege, die an Hauseingängen enden (Endnode ist Teil eines 
building-ways und hat entrance=main/yes)
E: Wege, die Zufahrten zu Garagen sind (Endnode ist Teil eines 
building=garage-ways)


Hallo zusammen,
danke für eure Meinungen. Das hat schon einiges Licht ins Dunkel gebracht.

Bei A und B herrscht ja ziemliche Einigkeit, dass noexit=yes bei A Sinn 
macht. Sobald man am Ende der Straße aber irgendwie weiterkommt (auch 
wenn die Straße als strikte Sackgasse ausgeschildert ist), darf kein 
noexit=yes hin.
Falls ihr nichts dagegen habt, würde ich dann auch das „streng genommen“ 
aus dem Wiki streichen, damit es eindeutig ist.
Bei C habe ich herausgehört, dass dort das noexit=yes-Tag akzeptiert 
ist, aber nicht unbedingt von allen aktiv gesetzt wird.
D und E waren noch nicht so ganz klar, insbesondere hat sich da gezeigt, 
dass das entrance-Tag an manchen Stellen präzisiert oder um Hilfstags 
ergänzt werden könnte (manche Zugänge zu Gebäuden sind _nur_ Eingänge, 
manche _nur_ Ausgänge). An der Stelle fällt mir ein: Gibt es ein Tag für 
Garagentore?
Ich persönlich bin aber gegen noexit-Tags bei D und E, da man (man = 
mindestens der Besitzer, manchmal noch mehr Leute ;-) ) durch die 
Tür/das Tor gehen kann.
Dann gab es noch die Fälle, wo Wege in der Natur oder abseits der 
öffentlichen Straßen einfach aufhören. Dort gilt in der Regel das selbe, 
wie bei A: Falls niemand dort weiterkommt, ist noexit=yes sinnvoll. Oder 
wenn der Weg an einem Hindernis endet (Mauer/Klippe/Zaun/...), sollte 
man das Hindernis einzeichnen und falls QA-Tools meckern, kann man noch 
ein noexit=yes dransetzen.


Allgemein kann man glaube ich sagen, dass dieses Tag (ähnlich dem 
fixme=continue oder note=*) ein Tag nur zur Kommunikation unter den 
Mappern und zur Signalisierung von false-positives an die QA-Tools ist.


Ich hoffe, das fasst so grob zusammen, was so gesagt wurde. Zu zwei 
Dingen würde ich dann noch etwas im Wiki festhalten: Zum einen das oben 
genannte „streng genommen“ streichen und zum anderen den Konsens zu den 
Wegen, die an Ein-/Ausgängen enden, eintragen (sobald es einen klaren 
Konsens gibt).


Viele Grüße,
Florian

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

[Talk-de] Meinungsbild noexit

[Florian Schäfer]

Hallo Liste,
ich würde gerne mal bei euch ein kleines Meinungsbild einholen über die 
Verwendung des Keys noexit 
https://wiki.openstreetmap.org/wiki/DE:Key:noexit.
Zum einen, ob ihr ihn nützlich findet, ihn benutzt, aber insbesondere 
_wo_ ihr ihn überall benutzt.
Denn mir scheint, dass es da die verschiedensten Auffassungen gibt, wie 
und ob er verwendet werden sollte. Deshalb dachte ich mir, ich schaue 
mal, welche Sichtweise am weitesten verbreitet ist.


In den folgenden Situationen habe ich beispielsweise schon 
noexit=yes-Tags gesehen:
*A*: Strikte Sackgassen auf öffentlichen Straßen (Zeichen 357 
https://commons.wikimedia.org/wiki/File:Zeichen_357.svg)
*B*: Durchlässige Sackgassen auf öffentlichen Straßen (Zeichen 357-50 
https://commons.wikimedia.org/wiki/File:Zeichen_357-50_-_Durchl%C3%A4ssige_Sackgasse_f%C3%BCr_Fu%C3%9Fg%C3%A4nger_und_Radverkehr,_StVO_2009.svg 
oder 357-51 https://commons.wikimedia.org/wiki/File:Zeichen_357-51.svg)
*C*: Privatwege auf Privatgrundstücken (z.B. Hausauffahrten 
https://wiki.openstreetmap.org/wiki/DE:Tag:service%3Ddriveway), die an 
dem einen Ende unverbunden sind
*D*: Wege, die an Hauseingängen enden (Endnode ist Teil eines 
building-ways und hat entrance=main/yes 
https://wiki.openstreetmap.org/wiki/Entrance)
*E*: Wege, die Zufahrten zu Garagen sind (Endnode ist Teil eines 
building=garage 
https://wiki.openstreetmap.org/wiki/Tag:building%3Dgarage-ways)


Die einzigen Anhaltspunkte, die ich dem Wiki 
https://wiki.openstreetmap.org/wiki/DE:Key:noexit dazu entnehmen 
konnte, waren:
* noexit=yes soll am „Ende von Wegen“ gesetzt werden. Aber was versteht 
man in diesem Fall unter einem Wegende und was nicht?
* „streng genommen“ soll im Fall *B* (s.o.) kein noexit=yes gesetzt 
werden. Aber soll man es jetzt immer streng nehmen ;-)?


Nun interessiert mich also:
*In welchen von den oben genannten Fällen findet ihr den Tag noexit=yes 
sinnvoll und wo nicht?* Und natürlich auch warum ihr das so seht.


Ich bin gespannt auf eure Meinungen zu dem Thema.

Viele Grüße,
Florian
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

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

[Florian Schäfer]

Am 03.02.2014 17:38, schrieb Martin Koppenhoefer:

Allein schon daher bin
ich für die ausgeschriebene Schreibweise im tag name (wg. internationaler
Konsistenz/gleichem Vorgehen, s.o.), es gibt aber noch mehr Beispiele.

+1

Ein weiteres Beispiel wäre da die St.-Exupéry-Straße, der ich neulich 
auch begegnet bin.
Da ist es durch die Bekanntheit des Namensgebers noch relativ einfach, 
aber wie wäre es mit der St.-Denis-Straße, St.-Martin-Straße oder 
St.-Paul-Straße? Die gibt es teilweise entweder als Sankt-Straße oder 
als Saint-Straße (insbesondere im französischen Grenzbereich).


Ich finde auch, dass der eindeutige (= ausgeschriebene) Name ins 
name-Tag gehört, alles andere in short_name u.Ä.


Gruß,
floscher

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

Re: [Talk-de] Fernbuslinien

[Florian Schäfer]

Am 10.12.2013 17:18, schrieb Falk Zscheile:
 Für welches Programm gibt es denn das Overpass-Plugin. In der
 JOSM-Pluginliste habe ich nichts dergleichen gefunden.

 Danke  Gruß Falk
Gemeint ist wohl das mirrored_download-Plugin für JOSM.
Da man verschiedene APIs damit abfragen kann, hat es halt nicht
Overpass im Namen.

Gruß,
floscher

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

Re: [Talk-de] Drohung an Mapper

[Florian Schäfer]

Hier ein Beispiel gerademal 1km vom Europapark bei Freiburg weg:
http://www.panoramio.com/photo/43124880
http://osm.org/go/0DJuhrMG?m=

Am 23.09.2013 20:02, schrieb Alexander Matheisen:
 Am Dienstag, den 24.09.2013, 02:22 +0900 schrieb Max:
 Interessante Entdeckung:
 eine Drohung an Mapper (an einer Mauer des Camp George in Daegu, Südkorea).

 Das Schild list sich so:

 WARNING
 RESTRICTED AREA

 This installation has been declared a restricted area by authority of the 
 Installation Commander in accordance with the provisions of the directive 
 issued by the Secretary of Defense on 20th August 1954, pursuant to the 
 provisions of Section 21, Internal Security Act of 1950. Unauthorized entry 
 is prohibited. All persons and vehicles entering herin are liable to 
 dearch.Photographing or making notes drawings, maps, or graphic 
 representations of this area or its activities are prohibited unless 
 specifically authorized by the commander. Any such material found in the 
 posession of unauthorized persons will be confiscated.

 (Darunter das gleiche noch mal auf Koreanisch)
 Solche Schilder findet man aber auch an US-Einrichtungen in Deutschland.
 Finde aber gerade leider kein Beispielbild (kein Wunder bei einem
 Schild, das das Fotografieren verbietet...)


 Gruß
 Alex


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

Re: [Talk-de] Naturtrails in OpenStreetBugs

[Florian Schäfer]

Am 04.05.2013 16:00, schrieb christian.pietz...@googlemail.com:

Einen reinen Fahrradweg (highway=cycleway) habe ich noch nirgends gesehen.
oO Der Sinn dieses Tags hat sich mir somit noch nicht offenbart.
Die gibt es häufiger. Und manchmal wird es mit der Beschilderung sogar 
sehr genau genommen:

http://cdn1.spiegel.de/images/image-54220-galleryV9-fbuh.jpg
(Direkt davor stehen übrigens nochmal vier Schilder, sodass man auf 
insgesamt 12 kommt. ;) )


Oftmals verlaufen diese parallel zu ausgeschilderten Fußwegen (räumlich 
getrennt durch Grünstreifen o.Ä.).


Gruß,
Florian

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

[Talk-de] Hausnummern

[Florian Schäfer]

Hallo Liste,
schon mehrere Male ist es mir passiert, dass die offizielle Hausnummer 
mit derjenigen, die am Haus hängt nicht übereinstimmt.


Beispiele:
1. Ich habe mal in der Hausnummer 6I (sechs römisch eins) gewohnt, bis 
ich beim Umzug bemerkt habe, dass im Grundbuch 6a steht.
2. Hier im Ort gibt es ein Doppelhaus an dem die Hausnummern 7 und 7a 
hängen. Laut Maps4BW vom Landesamt für Geoinformation und 
Landentwicklung [1] hat dieses Haus die Hausnummern 9 und 9a.


Was meint Ihr, soll ich lieber die Hausnummer am Haus mappen, oder die 
offizielle Hausnummer?


Gruß,
Florian

[1]: 
https://www.lgl-bw.de/lgl-internet/opencms/de/07_Produkte_und_Dienstleistungen/Open_Data_Initiative/index.html


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

Re: [Talk-de] Hausnummern

[Florian Schäfer]

Danke schonmal für die Reaktionen. Ich denke, ich werde demnächst mal 
bei der Stadt nachfragen, was da los ist.


 Welche Hausnummer hat die offizielle 7, so es sie denn gibt?
 An welchem Haus, falls existent hängt die 9, und welche offizielle 
Nummer existiert dort?


Es gibt keine offizielle 7. Ebenso hängt an keinem Haus die 9.

Momentan habe ich es so wie Steffen gemappt, da die Leute (Briefträger, 
...) mit dieser Nummer in Berührung kommen. Es war mir aber schon eine 
Weile ein Dorn im Auge.


Danke und Gruß,
Florian

Am 23.04.2013 15:48, schrieb Ruben Kelevra:

Ich würd den Weg von René beschreiten und die Gemeinde fragen was dort los ist.

Am 23. April 2013 15:46 schrieb Steffen Heinz eifelhu...@gmx.de:

Am 23.04.2013 15:13, schrieb Florian Schäfer:


Was meint Ihr, soll ich lieber die Hausnummer am Haus mappen, oder die
offizielle Hausnummer?



die die der Briefträger braucht ?   ;)

Grüße aus der Eifel
Steffen


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

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



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

Re: [Talk-de] Hausnummern

[Florian Schäfer]

Hallo,
vielen Dank für die ausführliche Antwort.
Inzwischen habe ich schon die zuständige Bauverwaltung angeschrieben. 
Mal schauen, was die mir antworten.
Außerdem habe ich den offiziellen Bebauungsplan der Stadt gefunden [1]. 
Dort stehen 9 und 9a drin (genau wie in Maps4BW).

Wie schon erläutert, wird von den Eigentümern die 7 verwendet [2].
Die Koordinaten des Hauses sind: 48,7465671 N 8,3447531 E

Gruß,
Florian

P.S.: Bin mal gespannt, worum es sich im OSM-Radio dreht (Thema: 
Hausnummern). ;)


[1] 
http://www.gernsbach.de/servlet/PB/show/1333483_l1/xn--bersichtslageplan%20Hardt-Grnling-eoc69h.pdf

[2] http://www.badenpage.de/gernsbach/luft/

Am 23.04.2013 17:15, schrieb Michael Reichert:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hallo,

Am 23.04.2013 15:13, schrieb Florian Schäfer:

Hallo Liste, schon mehrere Male ist es mir passiert, dass die
offizielle Hausnummer mit derjenigen, die am Haus hängt nicht
übereinstimmt.

Beispiele: 1. Ich habe mal in der Hausnummer 6I (sechs römisch
eins) gewohnt, bis ich beim Umzug bemerkt habe, dass im Grundbuch
6a steht.

6I klingt falsch, 6a klingt schon mal richtiger. Die 6I ist
wahrscheinlich ein Schreib-/Übertragungsfehler. Offiziell gibt es in
Baden-Württemberg (das weiß ich von meiner Tätigkeit in der
Vermessung) nur Hausnummern nach dem Schema 6, 6/1, 6/2, ... (lies:
sechs durch eins). Einige badische Gemeinden setzen sich über die
Anweisung des LGL hinweg und verwenden 6, 6a, 6b, ...

Wie Hausnummern in Baden-Württemberg vergeben werden und dass diese
eine Eigenschaft des Gebäudes sind, habe ich vor Kurzem im Forum
erläutert:
http://forum.openstreetmap.org/viewtopic.php?pid=328066#p328066


2. Hier im Ort gibt es ein Doppelhaus an dem die Hausnummern 7 und
7a hängen. Laut Maps4BW vom Landesamt für Geoinformation und
Landentwicklung [1] hat dieses Haus die Hausnummern 9 und 9a.

Was meint Ihr, soll ich lieber die Hausnummer am Haus mappen, oder
die offizielle Hausnummer?

Ganz offiziell ist die LGL-Nummer auch nicht. Ich vermute mal folgende
Ursache:
1. Gebäude wird gebaut (Bau ist genehmigt)
2. Gebäude wird von einem Vermesser* eingemessen, dabei erfasst der
Vermesser die Lagebezeichnung (Straßenname und Hausnummer). Wenn am
Gebäude schon eine Hausnummer hängt, übernimmt er i.d.R. diese. Wenn
das Gebäude noch nicht ganz fertig (aber schon verputzt) ist, schaut
man einfach auf dem roten Punkt (Baufreigabe)**, der auf der Baustelle
ausgehängt sein muss, nach der Hausnummer.
3. Im Innendienst wird der Veränderungsnachweis gefertigt. Auch hier
kann ein Übertragungsfehler auftreten.
4. Auf dem Vermessungamt wird die Vermessung auf fachliche Korrektheit
und Konformität mit den Vermessungsvorschriften überprüft und ins
Liegenschaftskataster übernommen. Auch hier kann man sich vertippen.

Ich würde, wie von einigen anderen schon empfohlen, mal die Gemeinde
ansprechen.

Viele Grüße

Michael



*) Mitarbeiter eines Öffentlich bestellten Vermessungsingenieurs oder
ein Beamter des Vermessungsamts
**)
http://www.homepage.eu/userdaten/0100210/083/bilder/foto/roter_punkt.jpg


PS Wo steht dieses falsch nummerierte Haus (7+7a/9+9a)?
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRdqV+AAoJEO7A7cvElxjaXQIH/0sByyIjn5zkAPx10ZlPxFqO
9NaBd2Jslkjrg0VLW6TS+En9/BzbjtBmi63ZIWt8legkP36n/eOWiL4kEzQDI2BU
ELAbXqEoIP07fgsQJ6dOFFqhh/bs0c5DXBp+GF0QMkzWGQJ/99sbR5p9lJYr4wKi
AzDtxQueHUrGhdVKAX2jhSFx3mQ4j/JRvGNpo5pBCdlkaYYFJQX5zZkuxGsfL23j
MkHXgYkcpLhiHmuIoUIkE1qKc5r/pf/7CZzyoQqRwu7BvYT0uZs1ev55Qfa50ZDT
E1TrBEy1PaPG9f9Ma3arbhVUfQ1k5sqtZm8/JwNCXOAaBdimgTz8ggCNK1xImXM=
=rtkt
-END PGP SIGNATURE-

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



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