Re: [Talk-de] oneway = no

[Tom Pfeifer]

Sicherlich kommt es vor, dass in Presets in Editoren gedankenlos
Default-Werte angekreuzt werden.

Wenn ich also auf der Autobahn ohnehin grade die maxspeed aktualisiere,
werde ich solch ein horse=no oder foot=no sicherlich stillschweigend entfernen,
wenn sich aus dem Kontext kein besonderer Grund für diese Werte ergibt.

Für oneway=no hatten sich in der Diskussion hier etliche Fälle ergeben,
in denen die explizite Betonung dieses Fakts sinnvoll ist.

Eine massenweise Entfernung von 2500 solcher Tags entbehrt aber die
Selektion nach sinnvollen und redundanten Situationen, insofern
sehe ich für den eingangs diskutierten mechanischen Edit keinen Konsens.

tom

On 23.05.2020 19:04, Volker Schmidt wrote:
> Aus welchem Grund siehst du das bei Radwegen anders als bei Strassen?
> Das Problem ist genau das gleiche.
> Dummerweise gibt es keinen tag value "positivly yes".im Gegensatz zu dem
> Ansatz missing tag fehlt = tag with default value.
> 
> Ich wuerde dich dringend bitten, wenigstens  in Zukunft keine Loeschungen
> von "vollkommen redundanten" tags mehr vorzunehmen. Danke im Voraus.
> 
> Volker
> 
> On Sat, 23 May 2020 at 17:07, Bernhard Kuisle via Talk-de <
> talk-de@openstreetmap.org> wrote:
> 
>> Ich verfahre in der Regel! auch so, dass ich oneway=no lösche, weil es
>> in meinen Augen oft vollkommen redundant ist.
>> Z.B. in ganz normalen Wohnstraßen in Wohngebieten.
>> Auf Radwegen in der Stadt kann es aber durchaus Sinn machen.
>>
>> Bernhard

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

Re: [Talk-de] Gewichtung der Straßen im Routing

[Tom Pfeifer]

On 28.04.2020 17:35, Florian Lohoff wrote:
> On Tue, Apr 28, 2020 at 03:17:16PM +0200, Tom Pfeifer wrote:
>> Entspricht denn lanes=1 der Realität?
>> Also der Verkehr in beiden Richtungen teilt sich eine Spur?
> 
> Wenn du aneinander vorbei möchtest muss einer auf die Bankette - ja -
> Mindest wenn die ein Trecker oder was breiteres entgegen kommt.

Gut, dann bin ich bei dir, was lanes=1 betrifft.

In England/Irland sind häufig noch engere Straßen anzutreffen, da hast
du statt eines Seitenstreifens hohe Trockensteinmauern oder Hecken.
Da muss einer zurückstoßen, bis irgendwo eine Feldeinfahrt oder Ausweichstelle
kommt.

On 28.04.2020 17:57, Volker Schmidt wrote:
> lanes=1 ohne oneway=no|yes wird von einigen (auch von mir als moeglicher
> Fehler) betrachtet, und ist daher keine gute Idee.

Nein warum - siehe oben.

On 28.04.2020 17:35, Florian Lohoff wrote:
> Die Frage war wie ihr das mit der relativen Gewichtung von
> Routingalternativen bearbeitet und fixed.

Es gibt den Tag "maxspeed:practical", der angibt, wie schnell man
realistischerweise auf einer Strasse vorankommt.
https://wiki.openstreetmap.org/wiki/Key%3Amaxspeed%3Apractical

Auch hierzu das Beispiel Irland - bei der Umstellung der Geschwindigkeiten
von Meilen auf Kilometer pro Stunde hatte man überall, wo das formale
Limit wechselt - typischerweise innerorts 50 und ausserorts 80 - die
rotumrandeten Schilder aufgestellt. Wenn also oben beschriebene
Straße, die sich auch alle paar Meter windet, und gleich der Trecker
um die Ecke kommen konnte, steht da 80 dran, obwohl man sich nur mit
15 vorsichtig vorantasten kann. Da hilft maxspeed:practical dem Router
zu mehr Realismus.

tom

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

Re: [Talk-de] Gewichtung der Straßen im Routing

[Tom Pfeifer]

On 28.04.2020 14:44, Florian Lohoff wrote:
> Nachdem ich dann die neue grünen teil mit lanes=1
> versehen habe ist soeben die route zurück geschwenkt.

Entspricht denn lanes=1 der Realität?
Also der Verkehr in beiden Richtungen teilt sich eine Spur?

tom

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

Re: [OSM-talk] Tag:manhole=telecom

[Tom Pfeifer]

Dear 80hnhtv4agou,

As OpenStreetMap is a worldwide project, we have to agree on a tagging scheme 
for an object that
is worldwide comprehensible.

We prefer to use the same tag for the same kind of thing.

Thus we prefer not to introduce synonyms or regional variations.

To make a feature be found more easily, "related terms" can be added in the 
wiki.

In the particular case, some friendly colleague has already added ‹ buried 
cable enclosure ›
to the manhole=telecom wiki page.

Kind regards
Tom

On 19.04.2020 17:20, 80hnhtv4agou--- via talk wrote:
> https://wiki.openstreetmap.org/wiki/Tag:manhole=telecom
>  
> in the united states this is not what it is called, so it was hard for me to 
> find to use.
>  
> can the name be changed.
>  
> https://www.multicominc.com/product/pencell-pem-2436-24x36x24-buried-cable-enclosure/
>  
> to what it is ?

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

[Talk-de] Brandenburg ist frei!

[Tom Pfeifer]

Steige hoch, du roter Adler!

Die Brandenburger Geobasisdaten, die von der Landesvermessung und 
Geobasisinformation Brandenburg
(LGB) seit Januar unter der "Datenlizenz Deutschland 2.0 Namensnennung 
dl/de/by-2.0" bereitgestellt
werden, können ab sofort für OpenStreetMap genutzt werden.

Die notwendige Zusatzvereinbarung war bereits in der BbgGeoNutzV "angedacht". 
In einem konstruktiven
Gespräch am 26.2. mit Vertretern der OpenStreetMap-Community in der LGB in 
Potsdam wurden die
letzten Details besprochen sowie Wege für künftige gegenseitige Kooperationen 
geebnet.

Die LGB hat sich nun im April 2020 dazu entschlossen, die notwendige Klausel 
allgemeingültig in
ihren Allgemeinen Geschäfts- und Nutzungsbedingungen (AGNB) aufzunehmen.

Damit muss der Quellenvermerk nicht im unmittelbaren optischen Zusammenhang zur 
Datendarstellung
eingebunden werden, wenn die LGB-Daten im Folgeprodukt nur einen 
untergeordneten Anteil haben und
dem Folgeprodukt mehrere Ausgangsquellen zugrunde liegen. Es genügt in diesem 
Fall, den
Quellenvermerk an anderer geeigneter Stelle beizugeben.

Das Neue an der Brandenburger Lösung zur DL/DD/by-2-0 ist, dass die 
Formulierung allgemein in die
AGB aufgenommen wurde. Dies, so schrieb Joachim Kast...
> könnte auch eine Anregung für weitere Bundesländer sein, die bisher ein 
> spezielles "Lex
OpenStreetMap" vermeiden wollten.

Damit auch noch einen dicken Dank an Joachim für seine Unterstützung auch in 
dieser
Behördenkommunikation.

Bei der Nutzung der Daten denkt bitte daran, dass auch amtliche Daten Fehler 
haben und stellenweise
nicht aktuell sind - gerade das weiß auch die LGB und würde hier gern mit OSM 
kooperieren.

Es ist eine Stärke von OSM, jegliche Daten, amtlich oder von wem auch immer, 
vor Ort prüfen zu
können, und mit vielen andere Quellen zu vergleichen und zu plausibilisieren. 
Pauschale Importe sind
in Brandenburg sicherlich nicht erforderlich bzw. unterliegen den bekannten 
Richtlinien.

Links für Details:

https://geobasis-bb.de/lgb/de/agnb/
https://wiki.openstreetmap.org/wiki/Brandenburg/Geoportal mit weiteren 
Rechtlichen Grundlagen
https://wiki.openstreetmap.org/wiki/Contributors#Brandenburg
https://forum.openstreetmap.org/viewtopic.php?pid=783554#p783554

Viele Grüsse
Tom

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

Re: [OSM-talk] JOSM: Display time of a gpx track

[Tom Pfeifer]

https://wiki.openstreetmap.org/wiki/JOSM/Plugins/InfoMode
is your friend:

  *  Displaying GPX trackpoint info - timestamp, velocity, height, track name 
and length.
  *  Hiding individual tracks and tracks older than selected.

tom

On 03.01.2020 19:36, tshrub wrote:

hi,
if I load gpx data as layer, how can I see the points & time from those?
With an extension I can see heights, that's fine.
Is there anything similar for the time - maybe popup-like when moving the mouse 
over it?
regards


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

Re: [Talk-de] Daten über Restriktionen und Vorrangrouten für den Schwerlastverkehr in NRW

[Tom Pfeifer]

Hallo Herr Spitzley,
es wird sich bestimmt noch jemand aus NRW zu Wort melden, ich mache mal den Anfang zu den 
allgemeinen Fragen.


On 21.11.2019 11:30, Spitzley, Bennedikt wrote:

Kommunen in NRW tragen auf der web-basierten Plattform SEVAS auf OSM Kartenwerk zum einen Lkw-Vorrangrouten ein. 


Die Nutzung von OSM-Material, z.B. als Hintergrundkarte, ist grundsätzlich ohne Einschränkung 
möglich. Einzige Voraussetzung ist die korrekte Attributierung, wie sie hier beschrieben ist:

https://www.openstreetmap.org/copyright


Zum anderen erfassen sie Lkw relevante Restriktionen: Lkw Durchfahrtsverbot 
(basierend auf Verkehrszeichen 253), Verbot für Gefahrgut (VZ 261), 
Beschränkungen in der Masse (VZ 262), Achslast (VZ 263) Breite (VZ 264, Höhe 
(VZ 265), Länge (VZ 266) und Verbot für wassergefährdende Ladung (VZ 269).
Diese Daten werden auf dem Mobilitätsdatenmarktplatz MDM bereitgestellt, wo Sie 
von Navigationskartenherstellern heruntergeladen werden können und so ihren Weg 
zunächst in die Navigationskarten und dadurch dann in die Lkw-Navigationsgeräte 
finden. Auch der Download über WFS- und WMS-Server ist möglich.
Gerne möchten wir diese Daten auch auf OSM veröffentlichen. Ob und wie dies 
möglich ist, möchte ich gerne hier diskutieren.


Das Einpflegen dieser Restriktionen in OSM ist grundsätzlich erwünscht, und in vielen Fällen auch 
schon durch die Community entsprechend der Ausschilderung vor Ort erfasst.


Es existieren folgende etablierte Attribute:

- hgv=no  Lkw Durchfahrtsverbot,
  https://wiki.openstreetmap.org/wiki/DE:Key:hgv

- hazmat=no  Einschränkung für Gefahrguttransporte,
  https://wiki.openstreetmap.org/wiki/DE:Key:hazmat

- hazmat:water=no Verbot für Fahrzeuge mit wassergefährdender Ladung
  s.o.

- maxweight=* juristische Gewichtsgrenze für die Benutzung der Wege
  * in Tonnen wenn ohne Einheit angegeben
  https://wiki.openstreetmap.org/wiki/DE:Key:maxweight

- maxaxleload=* beschreibt die maximal zulässige Achslast in Tonnen.
  https://wiki.openstreetmap.org/wiki/DE:Key:maxaxleload

- maxwidth=* maximal zulässigen Breite eines Fahrzeuges, in Metern
  https://wiki.openstreetmap.org/wiki/DE:Key:maxwidth

- maxheight=* Beschränkung der Durchfahrtshöhe auf Straßen, in Metern
  https://wiki.openstreetmap.org/wiki/DE:Key:maxheight

- maxlength=* Verbot für Fahrzeuge über tatsächliche Länge, in Metern
  https://wiki.openstreetmap.org/wiki/DE:Key:maxlength

Die Voraussetzung für das Einpflegen der behördlichen Daten ist die Veröffentlichung unter einer 
geeigneten Lizenz, bzw. hilfsweise eine Zusatzgenehmigung durch den Besitzer der Daten.


Ein typisches Problem bei scheinbar freien Lizenzen ist oft wiederum die Attributierung, die bei OSM 
nicht mehr am Endprodukt erfolgen kann, sondern typischerweise am Änderungssatz beim Einpflegen.

Gute Beispiele für notwendige Zusatzklauseln findet man hier:
https://wiki.openstreetmap.org/wiki/Contributors#Germany

Wenn Sie die Daten der Community z.B. per WFS/WMS anbieten, wird dies sicher gern angenommen, und 
die Mitglieder vor Ort können die behördlichen Daten mit der Ausschilderung vor Ort und der bereits 
erfolgten Erfassung in OSM abgleichen.


Interessant wäre hier ein Rückkanal. Da auch behördliche Daten Fehler aufweisen, könnte so darauf 
hingewiesen werden, dass die Situation z.B. vor Ort anders ausgeschildert ist als im WMS dargestellt.


Das manuelle oder automatische Einpflegen eines kompletten fremden Datensatzes in OSM gilt als 
Import, hierzu gibt es Richtlinien zur sorgfältigen Planung und Zustimmungspflicht seitens der 
Community, insbesondere damit Daten nicht gedoppelt oder verschlechtert werden:

https://wiki.openstreetmap.org/wiki/Import

Ich hoffe, das hilft zunächst zur Orientierung...
Ich habe Sie zunächst in CC genommen, typischerweise sollten Sie die Mailingliste aber bereits 
abonniert haben.


Tom

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

[OSM-talk] routing over bollards mapped as linear ways

[Tom Pfeifer]

The wiki allows barrier=bollard on a way. It demands however:
"If rows of bollards are laid across highways, make sure they share nodes with what they block since 
routing happens at the edges of area highways at present."


Indeed bollard is used 331k on nodes and 12k on ways.

While the wiki statement above has a focus on areas, the situation is already complicated for a 
router calculating on a linear way.


Assume we have a road that is blocked with several bollards across, which are mapped as a way, 
sharing a node with the highway. This sharing node is currently untagged.


A router would normally evaluate its routing graph for specific nodes on it, not necessarily 
evaluate any way that crosses it. Thus it finds barriers as a node, or traffic lights.


To consider the barrier-way just sharing a node, the router would need to evaluate each and every 
way it intersects for a barrier tag, which is a high extra load. We had a similar discussion a while 
ago when a user proposed to join two roads entering and exiting a roundabout in the same node.


Thus my questions;

- which routers currently evaluate way-barriers across a road based on an 
untagged shared node?
- should we required extra tagging of the shared node, or abolish such way 
barriers?

For bollards, it might be easy to map them individually, having one squatting 
on the road way.
For other barrier types, such as gates, this might be trickier.

cheers
Tom

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

Re: [Talk-de] Frage zu OSM-IDs

[Tom Pfeifer]

Insbesondere wird ein Element nicht physisch gelöscht, sondern in seinem XML-Code das Attribut 
'visible' auf 'false' gesetzt. Es wird quasi nur unsichtbar. Daher ist es möglich Löschungen 
rückgängig zu machen, also zu revertieren.


Siehe https://wiki.openstreetmap.org/wiki/Elements
Common attributes -> visible

Tom

On 10.10.2019 11:43, Martin Scholtes wrote:

Hallo,

die ID´s werden hochgezählt und nicht neu vergeben, da sonst ja die
history i-wann kaputt geht.

Gruß

Am 10.10.2019 um 11:40 schrieb Hövelmann, Marcel:

Hallo in die Runde,
folgende Frage meinerseits in die Runde:
Wenn ein Objekt gelöscht wird, z.B. mit der ID „node:4571570286“ – wird diese 
node-ID irgendwann nochmals neu vergeben oder neue nodes immer nur 
„hochgezählt“?


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

Re: [Talk-de] GPX-Track nutzen und hochladen

[Tom Pfeifer]

On 15.09.2019 10:15, Markus via Talk-de wrote:

habe ich beim OSM-Daten runterladen auch GPX angekreuzt.
Nun sehe ich zwar magenta Linien, aber die laufen waagrecht bzw. in
engem ZickZack - eine Spur kann ich nicht erkennen.


Sehe ich auch manchmal, ich vermute dass sind Punkte, deren Zeitstempel fehlt oder nicht öffentlich 
ist, so dass dort der Zusammenhang zum Track fehlt und verschiedene vermischt werden.



Wie kann ich mit JOSM meinen GPX-Track zur Nutzung für Dritte hochladen?


Beim Suchen in den Plugins fuur JOSM habe ich das gefunden, aber keine 
Erfahrung damit:

DirectUpload Plugin in JOSM
https://wiki.openstreetmap.org/wiki/User:Subhodip/GSoC_Doc#DirectUpload_Plugin_in_JOSM_:

tom

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

Re: [Talk-de] Mainnav MG-950d - Software

[Tom Pfeifer]

On 14.09.2019 19:37, Markus via Talk-de wrote:

Liebe Mapper,

wer kann mir von obigem Datenlogger die Auswertungs-SW schicken?


Auf der OSM-Wikiseite zu dem Gerät [1] ist eine Software auf code.google.com 
[2] verlinkt.

[1] https://wiki.openstreetmap.org/wiki/DE:Mainnav
[2] https://code.google.com/archive/p/mainnav-reader/wikis/ReadMe.wiki

tom

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

Re: [Talk-de] Gültigkeit von Verkehrsschildern nur in eine Fahrtrichtung?

[Tom Pfeifer]

On 08.09.2019 00:17, SteMo via Talk-de wrote:


Moin zusammen,

ich konnte nach einigem Suchen bisher nichts dazu finden. Gibt es für
das folgende eine Mappingmöglichkeit:

Ich bin inzwischen auf mehrere Straßen und Wege gestoßen bei denen ich
von einer Seite Durchfahrtsbeschränkungen der Art "Durchfahrt verboten,
Land- & Forstwirtschaftlicher Verkehr frei", von der anderen Seite aber
keinerlei Schilder die Durchfahrt beschränken. Ja, absurd, aber ist nun
mal so, nur wie mappe ich das jetzt? insbesondere, wenn ich keine
eigenen Linien je Fahrtrichtung, wie bei Autobahnen, habe.


Nein absurd ist das nicht, ich habe solche Situationen gesehen, dass man die Einfahrt in eine 
Wohnstrasse von der Hauptstrasse aus verbietet, die Wohnstrasse selbst aber nicht zur Einbahnstrasse 
erklären will. Z.B. um Stauumfahrung durch das Wohngebiet zu vermeiden.


Lässt sich fürs Routing lösen, indem man an der verbotenen Einfahrt ein paar Meter Einbahnstrasse 
deklariert (in deinem Fall mit Zusatztag für den Traktor).


tom

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

Re: [OSM-talk-ie] Main road deleted in error

[Tom Pfeifer]

https://simon04.dev.openstreetmap.org/whodidit/ was helpful here,
showing two changesets from a new user in this area.

https://www.openstreetmap.org/changeset/73950349 contains the problem.

https://www.openstreetmap.org/way/95719417/history has been undeleted now, 
connectivity appear ok.

On 01.09.2019 21:26, Colm Moore wrote:

Hi,

Shangort Road in Galway city has been deleted. I'm not sure how to find the 
changeset to undo this.

Any ideas?

Colm



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

Re: [Talk-de] Wegstücke Emscher Region (NRW)

[Tom Pfeifer]

Hallo Nora,

etwas Sorgen bereitet mir noch diese Aussage:

> Die shp-File selbst dürfen wir nur Projekt-Intern benutzen, also nicht an 3. 
weitergeben.

Hier muss unbedingt geklärt werden, ob der Rechteinhaber der Dateien der Ableitung von Inhalten nach 
OpenStreetMap zustimmt, in einem solchen Fall bitte schriftlich, und die Genehmigung veröffentlichen.


Bitte lies zuerst hier: https://wiki.openstreetmap.org/wiki/Copyright
und dann hier hinsichtlich der Offenlegung der Genehmigung:
https://wiki.openstreetmap.org/wiki/Contributors#Germany

tom

On 09.08.2019 11:27, chris66 via Talk-de wrote:

Hallo Nora,


a) Auf welche Art und Weise könnte man die vorliegenden Daten am
zeiteffizientesten UND im Sinne von OSM zielführendsten einarbeiten?
Import von shp-Dateien (??), manuelles Einarbeiten? 

Manuell, da ein Import bestehende Daten doppeln würde.


b) Welches Browser-Format (zb JOSM?) sollte man dafür nutzen? Im
beginners' guide steht als Schritt 2: upload data und in schritt 3: mit
josm bearbeiten. ist das hierfür auch zutreffend?


Als Editor sei JOSM empfohlen.

c) Wäre ich als unerfahrene Person diejenige, die das am besten einfügt oder würde das 
üblicherweise jemand anders tun, der sich damit bereits auskennt um fehler zu vermeiden? Oder 
hängt das von der Vorgehensweise ab?


Am besten wäre natürlich selber machen. Nach den ersten Edits
diese durch die Community begutachten lassen.

d) was wäre der tag für die Straßen, die noch nicht öffentlich sind, vermutlich sowas wie "special 
road type/service“?


Als Wegeklassen (highway=*) kommen in Frage: footway/cycleway/path/service mit passenden 
access-Tags, zB. access=no / private.


e) gibt es zur Diskussion dessen eine kleinere lokale zuständige Gruppe für NRW oder das 
Ruhrgebiet ... oder eine thematisch passendere ... oder bin ich hier richtig?


Es gibt lokale Usergruppen / Stammtische.

Chris


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

Re: [OSM-talk] Reordering and rewriting Good Practice wiki page

[Tom Pfeifer]

On 04.07.19 05:53, Joseph Eisenberg wrote:

I've reordered and reworded several sections of the Good practice
page: https://wiki.openstreetmap.org/wiki/Good_practice


On 04.07.2019 11:27, Frederik Ramm wrote:

I would prefer if far-reaching edits to essential pages that describe a
community consensus would be made on a user page first so we can
discuss, rather than applying the "be bold" motto here. 


That would also avoid dozens of small editorial edits, going back and forth, 
among the structural ones.


This is not to criticise the edits you made, just a matter of principle.
In fact I find our edits make sense and generally improve the page.


Well, I do criticize that paragraphs, which have been restored after your removal, and a reason was 
given in the comment for restoring, is being removed again in a later edit, following you personal 
opinion. Please don't start edit wars.


tom

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

Re: [OSM-talk] Ways divided by paint?

[Tom Pfeifer]

On 03.07.2019 22:03, Jack Armstrong Dancer--- via talk wrote:
I've always had the impression we should not create separate traffic lanes unless "traffic flows are 
physically separated by a barrier (e.g., grass, concrete, steel), which prevents movements between 
said flows."


Yes, I agree in general. Nearly all cases can be modelled with turn:lanes (and 
maybe change:lanes).


https://www.openstreetmap.org/edit?changeset=70997250#map=20/39.57354/-104.98496


This case -- and the aerial image is necessary to understand it -- would be one of the few 
exceptions where I would tolerate the current mapping of a separate lane for the left turn.
Otherwise a navigation engine would not be able to create the appropriate turn instruction at the 
point where the lane forks off. A much more complicated data model would be necessary.


tom

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

[Talk-de] Berliner Geoportal unter Datenlizenz Deutschland / Zusatzvereinbarung erfolgreich erneuert

[Tom Pfeifer]

Per 6.6.2019 stellte das Land Berlin [1] die bisher selbstformulierten Nutzungsbedingungen von 2013 
[2] auf die Datenlizenz Deutschland Namensnennung - Version 2.0 DL-DE-BY [3] um.


Dank der guten Kommunikation unseres Behörden-Ansprechpartners Joachim Kast wurde die seit 2013 
vorliegende Zusatzvereinbarung, im Fall OSM den geforderten Quellenvermerk an anderer geeigneter 
Stelle anzubringen, erneuert.


Sie liegt uns nunmehr als Briefbogen vor [4].

Dieses Schreiben sollte auch in der Kommunikation mit anderen Bundesländern  als Mustervorlage 
hilfreich sein, die sich dieser Zusatzklausel zur DE-Lizenz noch verweigern.


Auch Benutzer, die bisher die Problematik der DL-DE-BY hartnäckig noch nicht 
verstanden haben,
können auf dieses Dokument verwiesen werden.

Tom

[1] Amtsblatt für Berlin Nr. 21 / 17. Mai 2019 / Seite 3231
[2] 
https://web.archive.org/web/20140409103912/http://www.stadtentwicklung.berlin.de/geoinformation/download/nutzIII.pdf

[3] https://www.govdata.de/dl-de/by-2-0

[4] 
https://wiki.openstreetmap.org/wiki/File:2019-06-03_Datenlizenz_Deutschland_Berlin_OSM.pdf

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

Re: [OSM-talk] correct (scholarly) attribution?

[Tom Pfeifer]

On 17.05.2019 18:33, Greg Troxel wrote:

Frederik Ramm  writes:


Hi,

if someone writes a scientific paper and wants to reference an OSM data
set they used, what would be the correct way to do that? Typically such
mentions contain author and name of the work, and publication place and
year. Or maybe the web-like "retrieved on ..."?


I vote for not retrieved on but the date the data was extracted from the
main database, looking like "openstreetmap.org vector map data,
OpenStreetMap Contributors, extracted -MM-DD HHMM UTC".

My impression is that the publication date is for things where a journal
publishes them, and perhaps self-published blog posts, but for something
that is continuously modified, it doesn't really make sense.

It's also good to give a second citation to a journal article that gives
an overview the project, and surely that exists by now.  But I think the
most important thing is an unambiguous pointer to both OSM and the epoch
of data.


I'd like to agree here, and to add a 'it depends': on what the paper is about.
A core issue in a scientific paper is about the repeatability of the described 
experiment.

Thus when the core message is that the author has measured 123456 km of 
motorways in country X,
she should describe the precise source and version of the data set used, and 
the method of counting.
Probably not in the literature reference, but in an appropriate section of the 
main text.

When, on the other hand, the paper is about the sociology of repetitive 
vandalism patterns,
the precise date of the database extract might be less relevant, and appropriate case studies would 
need to be cited.


tom

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

Re: [OSM-talk] Questionnaire

[Tom Pfeifer]

On 23.03.2019 10:56, Daniela Šedlárová wrote:

Good day,
My name ist Daniela and I´m a student of geography. Please fill out the questionnaire for my thesis. 
The It takes you about 10 minutes.


Daniela,

First, I consider it impolite to jump into a mailing list (apparently not the only one), and request 
others to work for you, without any explanation:


- what university/college you are studying at,
- what the topic of the research is in general,
- what you are trying to find out specifically,
- where we can see any results.

Others have already criticized that posting a link to an arbitrary document is 
counterproductive,
I would not click such a link as it could be a scam.

Finally, at least in Europe where I know it, preforming an online survey would be considered to be 
research involving humans as participants, and require an Research Ethics approval from your 
university, which you should have applied for. You would need to consider how personal data are 
processed in this context.


Here are some explanations from universities, your favourite search enigne will 
deliver more examples.

https://www1.uwe.ac.uk/research/researchethics/frequentlyaskedquestions/studentresearchfaqs.aspx
https://www.st-andrews.ac.uk/utrec/guidelinespolicies/onlinesurveysandquestionnaires/

Kind regards
Tom

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

Re: [Talk-de] Fwd: Adressmapping auf Building-Relationen oder Outline

[Tom Pfeifer]

Die type=building-Relation ist ja eine Erweiterung für 3D-Mapping.

Eigenschaften, die das ganze Gebäude betreffen, sollten daher auf dem Gebäudeumring liegen, der auch 
ohne 3D-Mapping da wäre. Also auch die Adresse.


Dann sieht ein Datenkonsument, der sich nicht für 3D interessiert, diese 
Eigenschaften in jedem Fall.

tom

On 10.03.2019 17:14, Martin Scholtes wrote:

Hallo,

doku hab ich grade nicht zur Hand, aber so auf die schnelle ist das ok,
da es sich ja um EIN Gebäude handelt.

mfg

Am 10.03.2019 um 17:10 schrieb MonkZ:

Moin,

Ich habe eine Adresse auf hier auf die Outline einer type=building
Relation gepackt:
https://www.openstreetmap.org/relation/9376367

Bin mir aber nicht sicher, ob diese nicht eher auf die Relation selbst
gesetzt werden sollte oder nicht?
Wie ist eure Einschätzung? Gibt es da belastbare Doku?

MfG
MonkZ


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

Re: [Talk-de] Höhenbeschränkungen und ihre (fehlende) Darstellung

[Tom Pfeifer]

On 25.12.2018 11:57, sepp1...@posteo.de wrote:
Keine der bisher von mir besuchten Webseiten und getesteten Routenplaner oder Karten OSM-basierend 
gibt derartige Informationen aus, da diese ausnahmslos für Pkw <2m Höhe ausgelegt sind. 
Spezialkarten hin oder her - reine Lkw-Navisoftware mit entsprechenden Daten ist teuer und im 
privaten Bereich für bspw. 3 Wochen Urlaub mit gemietetem Camper einfach mal unerschwinglich. Da 
mittlerweile selbst normale Hochdachtransporter ausgeschlossen werden, macht das spätestens ab jetzt 
für das normale Routing Sinn, derartige Informationen SICHTBAR zu machen. Es gibt auch genügend 
Anhänger, die hinter einen Pkw hängend die Höhe von 2m überschreiten und das normale Navi macht das 
schlicht und ergreifend nicht! Mir sind auch schon Durchfahrtshöhen von 2,30m unter gekommen - da 
braucht man nicht einmal mehr einen Transporter mit Hochdach um dran hängen zu bleiben. Wie ist das 
beim Besuch im Baumarkt mit dem Miettransporter - Lkw-Navisoftware kaufen oder einfach (vorhandene) 
Daten sichtbar machen?


OsmAnd -> Settings -> Navigation settings -> Height limit.
Gerne auch Weight limit.

Weihnachtliche Grüsse
Tom

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

Re: [Talk-de] Rein unterirdische Gebäude?

[Tom Pfeifer]

Unsere Mapperkollegen im Geoportal/ALKIS/Berlin unterscheiden jedenfalls "Gebäude" und "Bauwerke", 
die ich in unterschiedlichen ALKIS-Layern aufrufen kann. In "Gebäude" finde ich sichtbare Häuser, 
während "Bauwerke" mir Tunnel, Brücken, flach überdeckte Tiefgaragen und bauliche Straßenanlagen 
liefert.


On 12.12.2018 07:08, sepp1...@posteo.de wrote:

Ich vermute, dass für den Renderer gataggt wurde, weil dieser mit Ebene <0 
nicht klar kommt?


Einer der Renderer diskutiert übrigens grade, wie unterirdische Gebäude/Bauwerke gerendert werden 
sollen:

https://github.com/gravitystorm/openstreetmap-carto/issues/552
https://github.com/gravitystorm/openstreetmap-carto/issues/3506


Also building=yes, building=parking, layer=-1 oder tiefer sind definitiv 
gerechtfertigt.


Der layer=* tag beschreibt ja nur die Lage von überlappenden Objekten 
zueinander.
Interessanter sind hier das Stockwerk level=*, parking=underground, 
location=underground

tom

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

Re: [Talk-de] service=driveway für alles was service ist?

[Tom Pfeifer]

Die Wiki-Seite wurde auf Ein- und Auffahrten fokussiert.

Ich hatte vor einiger Zeit mal auf 'tagging' angeregt, ein service=* subtag für die übergeordneten 
Servide-roads zu definieren, die in Carto als 'major' gemappt werden, damit die 
Vollständigkeitsfanatiker etwas zu taggen haben, wenn es eben keine untergeordnete (minor) 
Service-road ist.


tom

On 28.11.2018 10:44, Volker wrote:



Am 28.11.2018 um 10:21 schrieb Martin Koppenhoefer:


sent from a phone


On 28. Nov 2018, at 08:35, Falk Zscheile  wrote:

Dein Verständnis zu driveway deckt sich mit dem meinigen. Das sind auch für
mich kurze Wege/Straßen, die als Zufahrt auf Grundstücke dienen (und keine
darüber hinausgehende Erschließungsfunktion für das Grundstück haben).


ich sehe das driveway auch für private Zufahrten, bei einem Ikea sähe ich den Weg der Anlieferung 
(sofern da nur Bedienstete und Lieferer fahren) evtl. als driveway, die Hauptzufahrten zum 
Parkplatz als nur service und die kleinen Stichstraßen, die nur dem Zugang zu Parkplätzen dienen, 
als parking_aisle


Der og. Wikiedit von 2016 ist problematisch.


Gruß, Martin



+1 Dem ist nichts hinzuzufügen



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

Re: [Talk-de] Einführung von Regeln für die Verwendung von Relationen mit type=multipolygon

[Tom Pfeifer]

On 23.11.2018 21:37, gmbo wrote:

Regeln einführen wäre meiner Meinung nach gegen das Prinzip von OSM.
Es gibt zwar schon welche wie Urheberrechtsverletzung, 


Es gibt viele Regeln, auch viel grundlegendere:
"Ein Knoten ist eines der grundlegenden Datenelemente in OpenStreetMap. Er besteht aus einem 
einzelnen georeferenzierten Punkt mit Längen- und Breitengrad."



Waldfläche usw., kann ich mir vorstellen, dass da ein Neumapper von
allein in die richtige Richtung läuft und auch erfahrenere Mapper davon
profitieren.


Das Problem sind weniger gutwillige Anfänger, sondern durchaus erfahrene Mapper,
die es aber nicht verstehen, im Team zu spielen, sondern eigene Vorstellungen von Datenmodellen auf 
Kosten der Arbeitszeit aller durchdrücken wollen.


On 23.11.2018 21:54, Florian Lohoff wrote:
> 2 Multipolygone die auffällig sind im Regierungsbezirk Detmold. (Mehr
> als 20 Outer)
> Dagegen stehen insgesamt 3742 Multipolygone die in Ordnung sind.
> Das macht 0.05% oder 0.5 Promille. Dafür brauchen wir Regeln?

Deine Statistik geht von der Hypothese aus, dass die Problemfälle 
gleichverteilt sind.
Sie sind aber eher auf die Stellen konzentriert, an denen sich die genannte Kategorie von Mappern 
gerade aufhält.


Auch sind MPs mit vielen Outern nur das eine Problem; grundlos aus Linienstücken zusammengesetzte 
kleine Objekte das andere.


tom

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

Re: [Talk-de] Einführung von Regeln für die Verwendung von Relationen mit type=multipolygon

[Tom Pfeifer]

On 23.11.2018 20:14, Florian Lohoff wrote:


Mit Problem meine ich: Haben wir community Member die die von dir
angesprochenen Dinge bewusst und absichtlich Produzieren obwohl sie sich
der Implikationen bewusst sind?

Ich bezweifle das - Nur mal so ein Beispiel.

- Niemand erzeugt Multipolygone von vorneherein mit mehreren Outer
   rings. Die entstehen erstmal ganz klein. 

Ja, haben wir, und etliche krasse Beispiele sind in dem Forumsthread zitiert.

Es gibt die "Teppiche" der bewussten Zusammenfassungen von beziehungslosen Teilflächen, um sie im MP 
einmal zu taggen, und ich bin auch auf Mapper gestossen, die ganz bewusst Reihenhäuser aus 
Legoblöcken einzelner gerader Wandstücken zusammensetzen.


tom

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

Re: [Talk-de] Änderungen highway=living_street / highway=service + living_street=yes

[Tom Pfeifer]

Auch ich würde hier keineswegs im Wiki eine Empfehlung geben, "living_street=yes" zu benutzen, 
insbesondere nicht in der deutschen Situation.


Ja, der Tag ist organisch gewachsen, aber nur mit 20% der 1 Mill 
highway=living_street.
3K davon sind übrigen Doppeltagging.

Ausglöst wurde der Wiki-Edit vermutlich duch das Carto-Ticket
https://github.com/gravitystorm/openstreetmap-carto/issues/3514,
der Wiki-Autor hat dort auch die Idee geliked, einen driveway grau zu färben.

On 16.11.2018 13:11, Martin Koppenhoefer wrote:

Am Fr., 16. Nov. 2018 um 10:31 Uhr schrieb Florian Lohoff :



Hi,
heute morgen wurde der Wiki artikel für die Living Street
ergänzt um den Zusatz:

 Wenn es sich um Zufahrtswege handelt benutze highway=service +
 living_street=yes.

Ich habe keine Diskussion zu dem Thema mitbekommen und ich hätte
mich auch deutlich dagegen ausgesprochen. Das ist in diverser
Hinsicht kaputt.




+1




Eine living_street ist eine living_street und kein service und vice
versa. Highway klasse eins mit der Klasse 2 zu attributieren ist einfach
per definition kaputt.




+1, das macht für mich auch keinen Sinn. Ich verstehe ehrlich gesagt auch
nicht, wie man eine highway-tag-Definition ohne Rücksprache ändern kann.
Außerdem sollten das Übersetzungen der Definitionen im englischen Wiki
sein. Andererseits gibt es 24 living_street=yes in der db, davon 222000
mit highway=service, davon aber nur 3035 service=alley (für die würde ich
es akzeptieren ;-) ).

https://taginfo.openstreetmap.org/tags/living_street=yes#combinations
Laut history ist das zudem ein organisch gewachsener tag, seit 2009 in
Benutzung, wie es aussieht überwiegend in Osteuropa:
https://taginfo.openstreetmap.org/keys/living_street#map




Ich verstehe den Ansatz das highway=service/driveway doof aussieht
in einem Wohngebiet mit living_streets, und das man das gerne
anders rendern möchte, aber das da oben ist eine Verquickung von
Highway klassen und Attributierung die geneigt ist das chaos
nur noch zu vergrößern.




living_street ist eine öffentliche Straße, driveway ist das nicht. (alley
schon).

Gruß,
Martin


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

Re: [Talk-de] POIs - Details - Gerichtsurteil

[Tom Pfeifer]

Ich glaube nicht, dass solch ein Fall mit einem OSM-Eintrag vergleichbar ist.

Es gab schon ähnliche Entscheidungen, ich erinnere mich an ein Arztbewertungsportal, welches Werbung 
der Konkurrenz einblendete, wenn die Ärztin keine Premiummitgliedschaft hatte.


Der entscheidende Unterschied scheint mir zu sein, dass die beklagten Portale/Netzwerke faktisch 
eine Mitgliedschaft erzwingen wollen; während OSM nur Fakten sammelt.


Ich tagge allerdings auch keine natürlichen Personen als operator=*, und es gibt etablierte 
Mechanismen in OSM, solche persönlichen Daten z.B. durch die DWG entfernen zu lassen.


tom

On 31.10.2018 22:30, Günther Zinsberger wrote:

Hallo!

Ich gebe ja bei POIs so viele Details an, wie ich zusammentragen kann. Seit ich diesen Artikel 
gelesen habe, bin ich so am Überlegen, ob das vorteilhaft ist:


https://www.heise.de/newsticker/meldung/Friseur-vs-Facebook-Netzwerk-muss-50-000-Euro-zahlen-4207193.html 



Ein Friseur wollte nicht akzeptieren, dass Facebook für sein Geschäft ungewollt Werbung macht. Er 
zog vor Gericht – und gewann: Facebook muss nun zahlen.
Gezim Ukshini aus Hannover ist nicht bei Facebook angemeldet und trotzdem war sein Friseurgeschäft 
mit einer Seite im sozialen Netzwerk vertreten. Diese ungewollte Werbung mochte der Friseur jedoch 
nicht hinnehmen: Er klagte gegen das US-Unternehmen – und gewann. Facebook muss nun ein 
Ordnungsgeld in Höhe von 50.000 Euro an Niedersachsens Landeskasse zahlen.


Irgendwie trifft das ja auch auf OSM zu (ein Geschäftsinhaber hat keinen OSM-Account und trotzdem 
ist sein Geschäft möglicherweise in OSM ersichtlich).


Klar, wenn sich ein User an uns wendet, dann entfernen wir natürlich den Namen und weitere Details, 
die ihn betreffen. Bloß, auf welche Art meldet sich ein unbedarfter User bei uns? Mit "Einen 
Hinweis/Fehler zu den Kartendaten melden" in der Hauptkarte? Und was, wenn so ein Hinweis nicht 
zeitnahe bearbeitet wird?


Wie ist eure Meinung zu diesem Urteil und seht ihr Auswirkungen auf OSM?


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

Re: [Talk-de] Abknickende Vorfahrt

[Tom Pfeifer]

On 29.09.2018 00:04, Bernhard Weiskopf wrote:

... Mein Festeinbau meldet "Folgen sie der abknickenden Vorfahrt".
Das kriegen wir Stand heute schon alleine durch die fehlenden Daten
nicht hin.

Hat sich da in den letzten Jahren was dran getan - Wollen wir da was dran
tun? Gibts da proposals?


Wie wär's denn damit:
https://wiki.openstreetmap.org/wiki/DE:Key:priority_road


Halte ich für unzureichend. Das Zeichen "Ende der Hauptstraße" sehe ich sehr selten. Viel häufiger 
ist eine Straße A gegenüber Straße B vorfahrtsberechtigt, gegenüber Straße C aber wartepflichtig. 
Das wird einfach durch ein Vorfahrtsschild ausgedrückt. Mangels "Ende der Hauptstr"-Schild müsste 
man Str A an einer willkürlichen Stelle splitten. Wenn es funktionieren soll, wird man um eine 
Relation nicht umhin kommen.


tom

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

Re: [Talk-de] Abknickende Vorfahrt

[Tom Pfeifer]

On 28.09.2018 21:06, Andreas Schmidt wrote:

Wenn man abbiegt, biegt man ab.
Ob die Vorfahrtsstraße mit abbiegt oder geradeaus geht, ist für die
Frage des Abbiegens irrelevant.

Wenn ich links abbiege, möchte ich eine Ansage haben, dass ich abbiegen
muss, ich muss ja auch den Fahrtrichtungsanzeiger betätigen und das
Lenkrad drehen.


Sehe ich ebenso.
Wir taggen ja derzeit noch nicht einmal die Vorfahrt als solches.
Ergo können wir auch keine abbiegende Vorfahrt taggen.

Lösen könnte man das vermutlich nur über Vorfahrtsrelationen, ähnlich den existierenden 
turn_restrictions.



Am 28.09.2018 um 19:42 schrieb Florian Lohoff:

Hi,
ich glaube ich habe vor 10 Jahren hier schonmal gefragt und damals
gab es nichts zum Thema abknickende Vorfahrt.

Derzeit modelliere ich immer die Topologie so das wenn man der
Vorfahrt folgt es keine Ansage gibt - D.h. das ganze ist halt
von den Winkeln wie eine Kurve in der eben eine Straße abzweigt.


In 'modelliere' lese ich ein 'knete ich die Topologie', damit sich das Navi wunschgemäss verhält. 
Halte ich für einen Fall des Modellierens für den Renderer.


Fällt mir eine Stelle ein, an der ich neulich durchgekommen bin, hat jemand die rechtwinklig 
abbiegende Hauptstrasse zu einem sanften Bogen gestaltet, und die geradeausfahrende Nebenstrasse in 
den Kurvenscheitel gesetzt. Und mich wunderte, warum die klare Abbiegesituation nicht angesagt wurde.


tom


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

Re: [Talk-de] Genauigkeit der Gemeindegrenzen

[Tom Pfeifer]

Im Wiki steht: "Die Genauigkeit der Gemeindegrenzen in OSM ist regional sehr 
unterschiedlich."

Ist das nicht richtig? In Berlin sind wir komplett verwöhnt, weil wir den Senat an der kurzen Leine 
halten, und er uns mehr gibt was wir brauchen. Unter anderem Flurstücksbegrenzungsgenaue Grenzen.


Das mag in anderen Ländern anders sein.

tom

On 31.08.2018 21:55, Markus wrote:

Im Wiki wird die Genauigkeit (Lage und Form) er Gemeindegrenzen als sehr
begrenzt beschrieben, zuletzt 2014, und man solle doch die
Landesvermessungsämter fragen:
https://wiki.openstreetmap.org/wiki/DE:Gemeindegrenze

Wie ist der aktuelle Stand?
Vielleicht kann man ja das Wiki aktualisieren?

Mit herzlichem 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] Wie nennt man diese geo-statistische Funktion

[Tom Pfeifer]

Markus, meinst du Isochronen? Das ist die Visualisierung, welche Orte mit einem bestimmten 
Reisemodus in gleicher Zeit erreichbar sind.

https://wiki.openstreetmap.org/wiki/Isochrone

Tobias, ist das eine Implementierung von Skoda selbst oder von dir selbst?

tom

On 27.08.2018 10:04, Tobias Wolter wrote:



On August 27, 2018 8:47:05 AM GMT+02:00, Markus  wrote:

Wie heisst die entsprechende Funktion?
(sowas wie "Dominanz" bei Gebirgen)


In der Graphentheorie nennen wir das einfach nur "kürzester Pfad/Weg"-Probleme, aber das 
ist in der Umgangssprache etwas misverständlich, da das "kürzeste" sich nicht eindeutig 
auf Strecke oder Zeit bezieht, sondern welche Metrik man auch immer gerade anwenden will.

Navis implementieren das dann üblicherweise mit einer Gewichtung nach 
Entfernung oder nach Fahrzeit. (Mein Skoda versucht ein Mapping nach 
ökologischer Auswirkung auf Basis einer selbstentwickelten Kostenfunktion.)

-towo




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

Re: [OSM-talk] As Google Maps Renames Neighborhoods, Residents Fume - The New York Times

[Tom Pfeifer]

On 16.08.2018 13:06, Andy Mabbett wrote:

This may be of interest:

https://www.nytimes.com/2018/08/02/technology/google-maps-neighborhood-names.html 


Scary. Can we revert Google?

tom

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

Re: [OSM-talk] highway=* + area=yes vs area:highway=*

[Tom Pfeifer]

On 10.08.2018 13:20, djakk djakk wrote:

No, all highways are areas :) Mapping them as a line is a manual generalization 
;)


1., yes. 2., no, it is a mental abstraction, necessary to apply the mathematical graph theory for 
routing.


On 10.08.2018 12:02, Tomasz Wójcik wrote:
> ... it looks like highway=* + area=yes isn't incorrect, it's just not 
documented.

As said before, it was documented already on the area=* page. It might need to be more explicit on 
the highway pages.


tom

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

Re: [OSM-talk] highway=* + area=yes vs area:highway=*

[Tom Pfeifer]

On 08.08.2018 12:49, Tomasz Wójcik wrote:
As highway=footway etc. tags are set to "should not be used on areas" on Wiki, and mapping them in 
combination with area=yes is not documented at all and considered as wrong tagging by part of users, 
there is a key "area:highway=*" (133k uses at the moment). Part of users still map footway areas as 
a combination anyway, propably because it's rendered by default style. Due to our rules, that we 
shouldn't have 2 active tagging schemes for the same feature, so we should discuss this topic.


There is nothing on the wiki page that explicitly discourages or deprecates the use of highway tags 
on an area, except the flag in the template that defines that a closed loop means it is not filled, 
in the absence of other tagging.


area=yes is the traditional tagging then to distinguish a closed loop from an 
filled area.

"some closed ways ... are assumed to be areas, but others, such as highway=footway are not, being 
treated as linear features instead, except when there is also an area=yes tag." [1]


"The area=yes tag is required for some closed ways when used to define an Area 
(polygon)"

area=yes is used nearly a million times, 300k with highway*

area=yes and highway:area=* have different purposes, the first for the occasional filled polygon, 
the latter for systematically mapping highway width and shape.


Thus, area=yes is _well_ documented, and I see no reason to change that.

[1] https://wiki.openstreetmap.org/wiki/Area
[2] https://wiki.openstreetmap.org/wiki/Key:area

tom

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

Re: [Talk-de] Vandale

[Tom Pfeifer]

Helipads auf der Kirche,
military=nuclear_explosion_site : Achtung! Gefahr von Stolli´s Fürze
privater Biergarten,
gelöschter Bäcker,
keine Antworten auf CS-Diskussionen.

Revert ist im Gange.


On 23.07.2018 17:15, dktue wrote:

Hallo,

ich bin zufällig über einen User [1] gestoßen der anscheinend in mehreren Changesets [2, 3] 
vandaliert hat.


Vielleicht könnt ihr mich unterstützen alle seine Changesets durchzuschauen (sind nur 34 Stück) um 
gegebenenfalls aufzuräumen.


Gruß
dktue

[1] https://www.openstreetmap.org/user/Fipspilot/history
[2] https://www.openstreetmap.org/changeset/48852784
[3] https://www.openstreetmap.org/changeset/53591859


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

Re: [Talk-de] building:levels, Altbau/Neubau

[Tom Pfeifer]

On 22.07.2018 17:00, Frederik Ramm wrote:

wenn man building:levels erfasst - das ist ja doch ein bisschen
einfacher als eine echte Höhenmessung - macht es ja einen ziemlichen
Unterschied, ob man es mit einem Altbau-Stadthaus mit 3,50m hohen
Stockwerken zu tun hat oder mit einem Neubau mit nur 2,40. Sollte man
das irgendwie mit erfassen?


Du kannst ja problemlos height= des Gebäudes ergänzen, ist nur vor Ort 
schwieriger zu erfassen.
Wenn die Stockwerkhöhe bekannt ist, kann man multiplizieren, wobei allerdings die Beletage auch 
höher sein kann als die Dienstmannwohnung darüber :-)


tom

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

Re: [OSM-talk] proposed mechanical edit - moving FIXME=* to fixme=*

[Tom Pfeifer]

On 03.07.2018 14:21, Dave F wrote:

it should be updated when the object is touched individually anyway, thus not 
spoiling the history


There's no difference doing it that way or with a bulk edit  - it will still be recorded in the 
history..


It is a major difference! Doing the mechanical edit touches the last_edited for _all_ objects, as 
pointed out by Michael, and makes an analysis for old objects significantly difficult. Doing it 
individually _while doing other edits on the object_ touches the history for an intended improvement 
of content, not some unimportant lowercasing.


Removes duplicated, reduces confusion, easier to search. 


Cannot confirm any of those from my perspective.
Age of the object is much more difficult to search, while ignoring the 
upper/lowercase is easy.


A good Spring clean improves the database.


Spring is over, however the database is improved all seasons by individual 
edits.


I really think this fear of bulk edits has gone too far.


There is no fear, there are long-standing rules that have reasons.

tom

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

Re: [OSM-talk] proposed mechanical edit - moving FIXME=* to fixme=*

[Tom Pfeifer]

On 03.07.2018 13:22, Dave F wrote:

Great, but why the objection to a mechanical edit, rather than individually? Doing it one by one 
still updates the last_modified attribute.


it should be updated when the object is touched individually anyway, thus not spoiling the history 
with unnecessary bulk edits that do not improve the data themselves.


tom

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

Re: [OSM-talk] proposed mechanical edit - moving FIXME=* to fixme=*

[Tom Pfeifer]

On 03.07.2018 12:44, Mateusz Konieczny wrote:

Not skill but knowledge - that fixme and FIXME have exactly the same meaning > 
I hoped that that in this case there will be no controversy at all and this minor 
duplication


On 03.07.2018 12:52, Dave F wrote:
> All the editors need to be checked to see if they're adding FIXME as default.

Yes, thus the logical consequence is that tickets are opened with the major 
editors,
to include that in the validators, and remind the users to fix the underlying 
issue.
When the object is edited without removing the fixme/FIXME, the validator could lowercase it while 
saving the object anyway.


This process was done with other tags that were found unnecessary, such as _created_by_ on objects, 
and very successful without bloating the history.


tom

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

Re: [OSM-talk] proposed mechanical edit - moving FIXME=* to fixme=*

[Tom Pfeifer]

On 03.07.2018 11:48, Mateusz Konieczny wrote:

see http://taghistory.raifer.tech
It [FIXME] was quickly growing up to 2013, slowed later and and since 2017 
usage is decreasing.


Fine, so let it die peacefully.

Interestingly, 'FIXME' behaves more naturally, while 'fixme' shows a lot of 
import activities.
Quite visible if you add first 'FIXME' than 'fixme' to http://taghistory.raifer.tech/, so you see 
the latter in the zoom for the former. (hit 'reset zoom' to change the ceiling then).


tom

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

Re: [OSM-talk] proposed mechanical edit - moving FIXME=* to fixme=*

[Tom Pfeifer]

On 03.07.2018 04:33, Jason Remillard wrote:> ... and I was quite surprised to find that FIXME> (an 
invalid key) was so prevalent in the database.

Who declared the uppercase version invalid? Where is the discussion to 
deprecate it?

The English fixme wiki page still declares "Alternate forms include FIXME=*"

Removing the FIXME tag reduces the learning curve for map editors. 


What specific skill is to be learned here?

> All of the editors have single-click access to the full history of the object, changes to the 
last modified time or last modified user isn't that big a deal for experienced editors.


To check the object history is something the new user learns later, so first she sees an object 
touched recently by an automated tool, and trusts its correctness.


On 03.07.2018 06:12, Yves wrote:
> I second Tom and Mikael, maybe a kind of rédaction to keep the date could be 
done? Not sure it's
> worth the effort though.

Thanks, but the effort would be even larger than a bot edit; and I agree with you and Fred that its 
not worth it.


On 03.07.2018 09:49, Mateusz Konieczny wrote:
> - removes common duplicate confusing people

I'm getting the impression that we cannot find agreements on more important confusions (grass and 
forest landuse/landcover for example), so we start looking at such decorative issues?


On 03.07.2018 10:12, Ed Loach wrote:
> ... FIXME pre-dates the fixme wiki proposal (if you dig out the proposal you'll see a discussion 
on the talk page about FIXME vs fixme when FIXME was still in the majority if you excluded an import 
which added 140,000 fixme entries) - indeed I didn’t even know there was a wiki proposal. The 
discussion on that wiki talk page decided it didn’t really matter about the case if I recall 
rightly, or this change would have been done years ago.


Ed, your analysis is correct, and probably people used the 'shouting' uppercase for FIXME so it 
jumps into the eye of the next editor more easily.


On 03.07.2018 10:56, Lester Caine wrote:
> On 03/07/18 09:28, Frederik Ramm wrote:
>> Don't forget that new FIXMEs will continue to appear all the time.
>> Software should be able to deal with both.
>
> I'm with you on this Frederik. The correct fix for a 'FIXME' tag is to deal 
with it or remove it
> completely if no longer valid, and adding extra change events to 'fixme' only gets in the way of 
that.


Fully agree. As the wiki page says: "This is not a tag for robots nor for any automated edits" - 
that should apply to both, the problem the individual fixme/FIXME marks, and the tag itself.


tom


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

Re: [OSM-talk] proposed mechanical edit - moving FIXME=* to fixme=*

[Tom Pfeifer]

On 03.07.2018 01:23, Michael Reichert wrote:

There are 177,152 FIXME and 1,216,043 fixme according to Taginfo. I did
not have a closer look on the average age of FIXMEs and fixmes.

What's the benefit in this mechanical edit? It just sets the
last_modified attribute to a recent date and data consumers, mappers and
QA tools get the impression that the object is not old.


This was my first thought as well.

As for mapping, I prefer to see the name of the last editor who changed content,
and not the name of the last bot who just lowercased a key.
In that case I need to dig into the history which is extra work for me.

The proposed edit does not improve data quality a single bit.

Fixmes are to be solved, not to be renamed.

Tom

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

Re: [Talk-de] landuse-Tag bei Sozialeinrichtung

[Tom Pfeifer]

Ich empfehle für das Grundstück
amenity=social_facility
social_facility=nursing_home

landuse halte ich in dem Fall für entbehrlich, da die Nutzung durch das flächige amenity-Tag bereits 
hinreichend beschrieben ist.


tom

On 11.06.2018 08:54, goegeo wrote:

Hallo Liste,

wie seht Ihr das? Ich bin gerade auf ein Grundstück mit bereits erfasstem amenity-Tag "nursing_home" 
gestoßen, bei der die Landnutzung noch nicht erfasst wurde. Dies wollte ich nun ergänzen. Habe mich 
im Wiki bei den Landnutzungen umgesehen und bin mir nicht sicher, ob wir es als residential oder 
doch commercial taggen sollen. Kann jemand bei der Entscheidungsfindung helfen?


Danke im voraus. Grüße, goegeo



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

Re: [OSM-talk] More secondary attributes for schools

[Tom Pfeifer]

On 27.05.2018 12:47, Gaurav Thapa wrote:
Recently, in Nepal we have been getting more and more requests from government and private schools 
to be able to upload more information about their schools to OSM. These in particular include 
detailed data such as number of boys in grade 1, number of girls in grade 5 and number of permanent 
staff etc. This data is nationally collected every year by schools and are seen as valuable in 
letting schools, communities and districts know where there are failing girls in the education 
ladder or to just understanding general diversity in schools.


The 'capacity' key is widely used for schools and kindergarten facilities, for the whole object, 
thus it indicates the size.


I would not encourage annual statistics about number of pupils in each grade in OSM. This can be 
overlaid from separate databases.


I was initially planning on posting this in the Nepal talk list but decided that this might be 
something other countries might be interested in as well hence sharing it here. Current, tags that I 
have found are more generic such as isced:levels=* and grades=*. Do you suggest that we propose tags 
specifically to Nepal or do you even think data such as this should be in OSM?


isced:levels=*  is internationally valid and widely accepted.
grades=* was recently pushed by an individual Canadian mapper and is controversial since it is 
heterogeneous in meaning between countries, and even within the same country different counting is 
used (e.g. starting to count grade 1 again for the secondary school).


tom

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

Re: [OSM-talk] what can be mapped - temporary, pernament and reoccuring

[Tom Pfeifer]

On 25.05.2018 20:54, Mateusz Konieczny wrote:



Mapping Christmas market appearing once a year starts to be weird.



Though that seems to be the exception for rare things - there is even a map renderer focusing on 
that season,

https://wiki.openstreetmap.org/wiki/OpenSantaMap (but the linked map seems down)
using the xmas: key:
https://wiki.openstreetmap.org/wiki/Key:xmas:feature

IIRC, OsmAnd has some Christmas gimmicks as well, not sure if it evaluates the 
above scheme.

tom

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

Re: [Talk-de] Attribute für Rettungswachen, Bergwachten, Hilfsorganisationen

[Tom Pfeifer]

Das Taggen der Hilfsorganisationen ist recht chaotisch, daher ist ja seit langem der 
"Emergency-cleanup" im Wiki annonciert, wird aber nur halbherzig betrieben.


Für die Bergrettung würde sich "emergency=mountain_rescue" anbieten, bisher 2 
Verwendungen.

Für den Zivilschutz hatte ein Australier mal "emergency=ses_station" etabliert, was wegen des 
nationalen Acronyms SES ungeeignet ist [1].


Bei den Diskussionen dort, ob emergency=disaster_response geeignet wäre, stieß ich auf die 
derzeitige Verwendung beim deutschen Technischen Hilfswerk (THW) nach dem Schema 
amenity=emergency_service + emergency_service=technical, was einem Proposal von 2008 [2] folgt.


[1] https://wiki.openstreetmap.org/wiki/Tag:emergency%3Dses_station
[2] https://wiki.openstreetmap.org/wiki/Proposed_features/Emergency_service

Tom

On 15.04.2018 14:04, Lena Essig wrote:

Hallo zusammen,

mir ist aufgefallen, dass bei der Suche nach "emergency"="ambulance_station"
nicht nur Rettungswachen angezeigt werden, sondern auch Bergwachten oder
auch Ortsvereine.
Nur sehr wenige der Bergwachten sind mit "amenity"="mountain_rescue"
getaggt.
Da Bergwachten nur besondere Einsatzarten übernehmen, sollten sie von
normalen Rettungswachen unterschieden werden. Ebenso Ortsvereine der
einzelnen Hilfsorganisationen, da sie nichts mit dem Rettungsdienst zu tun
haben.
Wie ist denn die allgemeine Regelung für Orstvereine oder
Katastrophenschutzzentren?



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

Re: [Talk-de] Navads-Tankstellenimport

[Tom Pfeifer]

On 28.03.2018 23:06, Falk Zscheile wrote:

Am 28. März 2018 um 21:58 schrieb Harald Hartmann
:

Hmm, geht's wohl schon in die nächste Runde?

weiter geht's mit http://audit.osmz.ru/project/navads_fuel_de


Das finde ich jetzt schon ziemlich gut. Man kann nun für jedes Node
sagen, ob man die Änderungen haben möchte oder nicht. Das sollte die
Qualität des (potentiellen) Imports deutlich verbessern und Datenmüll
vermeiden. Und einen Fortschrittsbalken, wie viele Daten schon geprüft
wurden, gibt es auch :-)


Wenn ich eine lokale Tanke herangezoomt habe, und als "good" bestätige, werde ich mit 
Überlichtgeschwindigkeit an einen anderen Ort in DE gebeamt, von dessen Existenz ich bisher nicht 
einmal geahnt habe. Nach lokaler Überprüfung sieht das dann nicht mehr aus.


tom

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

Re: [Talk-de] Tagging von kombinierten Wohn- und Geschäftshäusern

[Tom Pfeifer]

On 05.03.2018 10:59, Martin Koppenhoefer wrote:

Am 4. März 2018 um 22:24 schrieb Volker Schmidt :

Nein, building=house ist ein Einfamilienhaus.


m.E. grundsätzlich nicht ganz klar und hat Potential für Verwechslungen.


Die Verwechslungsgefahr besteht insbesondere im Deutschen wegen der Ähnlichkeit von house und Haus 
mit unterschiedlicher Semantik.


Derzeit ist building=house mit 25 Mill Verwendungen der zweithäufigste Wert 
nach 'yes' [1]
Die Definition "A single dwelling unit usually inhabited by one family" ist 
eigentlich glasklar.


Ich würde eher explizit vorgehen:

building=detached_house Einfamilienhaus


Üblich ist die kompaktere Form, building=detached (1,1 Mill), die im Englischen auch als Substantiv 
gebraucht wird.



building=semi_detached_house Doppelhaushälfte


building=semidetached_house (51 K, no wiki), =semi (16 K, wiki) =semi_detached 
(0.6 K, no wiki)


building=terraced_house  Reihenhaus


sehr wenig getagged. Die zusammenhängende Reihe (building=terrace) sehr viel, 470 K, aber die 
einzelenen Einheiten: =terraced_house, =terraced zusammen weniger als 0.2 K


[1] https://taginfo.openstreetmap.org/keys/building#values

tom

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

Re: [OSM-talk] Danger zone for pedestrians

[Tom Pfeifer]

On 27.02.2018 12:58, Martin Koppenhoefer wrote:
Mapping perceived danger has been discussed some years ago, and AFAIR wasn't considered to be 
verifiable. Tried to find the discussion but couldn't, you might try yourself with your favorite 
search engine.


It was on the tagging list, see the start here:
https://lists.openstreetmap.org/pipermail/tagging/2016-November/030581.html

Besides the verifiability problem, such tagging would discriminate one demographic group against 
another, and increase the cultural bias in OSM.


I remember when I asked a car rental agent for zones to avoid, he kindly marked areas on the map for 
me, but it was not printed on them.


tom

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

Re: [Talk-de] Tagging von kombinierten Wohn- und Geschäftshäusern

[Tom Pfeifer]

On 04.03.2018 18:38, Harald Hartmann wrote:

aus [1] lese ich z.B. heraus, dass residential auch nur ein sehr
allgemeiner abstrakter Oberbegriff ist, den es eigentlich zu verfeinern
gilt (wie z.B. bei surface=paved)

Mir ist aktuell kein building Wert bekannt der ausdrückt, dass es ein
Wohnhaus ist, in dem auch noch Geschäfte (z.B. eine Bäckerfiliale)
untergebracht ist, deshalb stimme ich wambacher erst mal zu,
building=house und dann noch ein POI fürs Geschäft.

[1] https://wiki.openstreetmap.org/wiki/Tag:building%3Dresidential


Das kommt ja nun auf die konkrete Situation an.

building=residential ist der Oberbegriff für ein Haus vorwiegend zu Wohnzwecken.
Befinden sich mehrere Wohnungen darin, ist es ein building=apartments.

In beiden Fällen wäre ein Laden im EG unschädlich, da der Wohnzweck überwiegt.

building=house ist ein klassisches Einfamilienhaus. In Verbindung mit einem Laden würde ich es nur 
verwenden, wenn der EFH-Charakter überwiegt, und z.B. ein winziger Laden im Souterrain ist.


tom


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

Re: [OSM-talk-ie] Round towers

[Tom Pfeifer]

On 18.02.2018 00:45, Colm Donoghue wrote:

When I looked to see how to tag the round tower there's nothing to suggest
that it's an Irish round tower documented in the wiki

I'm proposing tagging all Irish round towers as man_made=irish_round_tower


I'd prefer to start with the more generic man_made=tower, and specify the round tower with 
tower:type, see https://wiki.openstreetmap.org/wiki/Key:tower:type


tom

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

Re: [OSM-talk] Roundabouts - why is a separate segment required?

[Tom Pfeifer]

On 14.02.2018 17:39, Dave F wrote:

https://www.openstreetmap.org/node/5408566797


It appears that you already engage in an edit war, although half a dozen people here tell you, from 
a variety of perspectives, that you are wrong.

https://www.openstreetmap.org/changeset/56352276

On 14.02.2018 18:27, Dave F wrote:
> I'm glad you mentioned mkgmap as I suspect this is where this mapping 
instruction originated. From
> previous conversations on their forum it's clear some try to fudge OSM as 
they lack the skill to
> program mkgmap correctly.

It would help to maintain objectivity to leave out any rants about particular programmers of 
particular software. I have seen other routing engines fail when the situation occurs that you have 
created.


On 14.02.2018 18:27, Dave F wrote:
> This would only occur if there was no check to see if it's a roundabout first:
>   * Enter
>   * Check if roundabout
>   * (While still on the same node) Start counting entrances/exits

In which routing engine did you implement this? From which experience do you 
speak?
Or is it just pseudocode that fell off your sleeve without being tested in an 
implementation?

On 14.02.2018 21:44, Mark Wagner wrote:

In the general case, a router only needs to consider the ways that a
route actually passes over when creating directions.  By mapping a
roundabout entrance and exit sharing a single node, you've
introduced a special case: the router now needs to check all ways
connected to that node to see if any of them is part of a roundabout.


Yes and to reiterate, to separate roundabouts from non-roundabouts, you would need to check that 
special case not only at roundabouts, you would need to check its absence at _any_ node connecting 
_any_ two road segments, even if these are not junctions. You would need to check if there starts a 
roundabout segment or not, and if all segments of such roundabout loop back to the original node.


As the check you propose is against the basics of graph theory which is behind routing algorithms, 
it would create an immense performance burden on the algorithms. That would make you mourn about the 
skills of the programmers, again.


May we ask you to undo your revert in CS 56352276? You still have not explained how the two node 
solution "fudge OSM".


tom

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

[OSM-talk] Limitations on mapping private information

[Tom Pfeifer]

While OSM has a Privacy Policy [1] regarding the data of OSM users, it appears we are lacking a 
central reference point about which personal data about individuals are to be mapped within the OSM 
database, and which not.


For the purpose, a wiki page has been created [2] which can be discussed here 
or on the talk page.
The intent is to embed a summary in the Good practice page [3], after 
consolidation.

[1] https://wiki.openstreetmap.org/wiki/Privacy_Policy
[2] 
https://wiki.openstreetmap.org/wiki/Limitations_on_mapping_private_information
[3] https://wiki.openstreetmap.org/wiki/Good_practice

Kind regards
Tom

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

Re: [Talk-de] Relationen Radweg gelöscht: Relation 6889944 - [6] Egerradweg

[Tom Pfeifer]

On 29.01.2018 08:01, osm_ww wrote:

Jetzt muss ich erkennen, dass die von mir erstellten Relationen zum Teil 
vollständig von einem anderen User (Glogi) gelöscht worden sind.
https://www.openstreetmap.org/changeset/55019975
Als Begründung wird nur kurz „add part of route 6“ angegeben.


Das ist für das Löschen von 7 Relationen keine sinnvolle Begründung. Wie Volker schon empfahl, nimm 
über die CS-Diskussion Kontakt auf. Glogi arbeitet aber offenbar auch an Routen, da wuare besinders 
wichtig zu wissen was er vorhat. Vielleicht war es ja ein Versehen, mit 200 CS fehlt vielleicht noch 
Erfahrung.


In dem Changeset hat er aber auch Relationen verändert, insbesondere eine mit name=6 in Version 91, 
die solltest du dir anschauen, vielleicht hat er die Routen ja nur anders zusammengebaut?



Was kann man in solch einem Fall machen?
Kann ein anderer User einfach solche Löschungen vornehmen?
(Insbesondere, wenn das Ergebnis der Änderung schlechter ausfällt als der 
Anfangszustand?)


Können schon, die Absichten müssen halt geklärt werden, siehe oben.


Kann ich den von mir erstellten Radweg (Relation 6.889.944) wieder vollständig 
herstellen?


Ja. Eine gelöschte Relation ist ja nicht wirklich weg, sondern nur als gelöscht 
markiert.
Da du mit JOSM arbeitest, wäre hier das https://wiki.openstreetmap.org/wiki/JOSM/Plugins/Undelete zu 
empfehlen, mit dem du gezielt einzelne Objekte reaktivieren kannst. Es empfiehlt sich, das erstmal 
als Trockenübung zu machen und zu schauen ob die enthaltenen Wege noch da sind.


tom


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

Re: [OSM-talk] GPS Watch

[Tom Pfeifer]

I'm always wondering why people would wear a GNSS logger on the wrist, where the 70% water mass of 
the wearer's body is always shielding half of the satellites.


On top of the head would be a much better position for the receiver, at least for the antenna, thus 
I wonder why there are so many GNSS watches, and no GNSS hats?


tom


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

Re: [OSM-talk] OSM website stats on the end of the year

[Tom Pfeifer]

What measurements are these estimates based on?

On 12.12.2017 02:00, Daniel Koć wrote:

I've just visited Alexa free stats on OSM website and here are some interesting 
facts:

- Current Global Rank for OSM: 6988 (down 833)

- Most visitors come from USA, Germany, China, UK and France (in both USA and China rank number is 
lower than global average, but probably much more people live there, hence #1 and #3...)


- In the last year percent of visitors coming from the search engines increased 
from ~20% to ~30%

- Most of the people were visiting Google, Yandex and Wikipedia sites 
immediately before

- 4/5 most popular keywords of searching visitors are related to OSM (fun fact: 
"bing maps" is #2...)

- Comparing to average "Internet population" there are much more males and less 
females


[ https://www.alexa.com/siteinfo/openstreetmap.org ]


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

Re: [Talk-de] Bemerkenswerte Relation

[Tom Pfeifer]

On 10.11.2017 17:51, Simon Poole wrote:

Am 10.11.2017 um 17:34 schrieb Tom Pfeifer:

Die Rollen "level_N" sind seit dem 14 March 2015 in type=building
dokumentiert [3]


Das war zu dem Zeitpunkt schon veraltet und wenn ich nicht wüsste wer es
da reingeschrieben hat, würde ich mich wundern.


SIT ist jetzt erstmal auf der Seite hinzugefügt. Sollte man dann die Ausführungen zu IndoorOSM als 
veraltet kennzeichnen?

Ganz löschen würde ich sie nicht, damit man bei Fragen wie hier die Herkunft 
des Taggings klären kann.

tom

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

Re: [Talk-de] Bemerkenswerte Relation

[Tom Pfeifer]

On 10.11.2017 16:35, dktue wrote:
> ich bin gerade auf diese bemerkenswerte Relation [1] gestoßen. Hier scheint 
mir einiges an
> Member-Rollen und Tagging-Schema erfunden zu sein.

Es handelt sich um eine Building-Relation [2], dabei wurden per Indoor-Mapping 
einzelne Etagen erfasst.

Das dabei entstehende Chaos sollte durch Strukturierung beherrscht werden, wozu eine Relation für 
das Gebäude weitere Relationen pro Etage enthält.


Die Rollen "level_N" sind seit dem 14 March 2015 in type=building dokumentiert 
[3]

> Wie würde die vereinfachte Form aussehen die nur auf übliches Mapping 
aufsetzt?

Was ist "üblich"? Indoor-Mapping ist üblich.

Bei der Level-Relation wurden "buildingpart" und "shell" verwendet, das habe ich bisher nur in einem 
Proposal [4] gefunden. Ob das auch durch die in der building-Relation gebräuchlichen "part" und 
"outline" ersetzt werden kann, müsste man prüfen.


On 10.11.2017 17:06, Simon Poole wrote:
> Das ist ein Gebäude das nach dem veralteten IndoorOSM Schema erfasst wurde,
> [...] http://wiki.openstreetmap.org/wiki/Simple_Indoor_Tagging entwickelt

Aha, danke, werde mal auf [2] drauf verweisen.

On 10.11.2017 16:52, Scholtes, Martin wrote:

Finde das tagging etwas zu ausführlich.
Warum sollte man jede Etage Einzel taggen?!


Damit man sie voneinander unterscheiden kann.


  Würde das gesamte Gebäude in einen Way räumen.


Wie meinst du das genau? Was räumen?

[1] http://www.openstreetmap.org/relation/2513418
[2] https://wiki.openstreetmap.org/wiki/Relation:building
[3] 
https://wiki.openstreetmap.org/w/index.php?title=Tag:type%3Dbuilding=prev=1149162
[4] https://wiki.openstreetmap.org/wiki/Proposed_features/IndoorOSM

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

Re: [Talk-de] Deutsche Namens-Tags in Polen

[Tom Pfeifer]

On 26.10.2017 14:56, Richard wrote:

Vielleicht mal als name:1939-1944 


Nein, als old_name:-, jetzt auch ordentlich dokumentiert.

https://wiki.openstreetmap.org/wiki/DE:Key:old_name

tom

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

Re: [Talk-de] Deutsche Namens-Tags in Polen

[Tom Pfeifer]

On 25.10.2017 16:58, Martin Koppenhoefer wrote:

Ist old_name eine Liste?


Eine Semikolon-Liste? Eher nicht, aber grade bei old_name bietet sich an, die 
Jahreszahlen anzugeben:

old_name:[]-= bzw. old_name:de:[]-=
bzw. auch mit genauem Tag.

Dann sortiert sich die Umbenennungspraxis schön in den historischen Kontext.

Hm, ich dachte das wäre besser dokumentiert :-( Die Wiki-seite ist nur ein 
Redirect auf name.

Beim blick auf
https://taginfo.openstreetmap.org/keys/old_name#similar
sind bei genauem Datum Varianten mit einem oder zwei Bindestrichen gebräuchlich:

old_name:1969-10-18-1970-01-01
old_name:1962-03-21--1965-02-11

On 25.10.2017 18:44, Markus wrote:
> Vielleicht kann ja die DWG prüfen, wer diese Einträge macht, und ggf. entsprechende Massnahmen 
ergreifen.


Das hat sie in offenkundigen Fällen ja auch bereits gemacht.

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

Re: [Talk-de] landuse=residential an Node

[Tom Pfeifer]

Fein.
Habe mir die Restposten angeschaut, es sind dort urbane bzw. ländliche Siedlungsstrukturen zu 
erkennen, zu denen der Name gemappt wurde, da eignet sich place=hamlet bzw. place=neighbourhood,

insbesondere wenn der landuse ohnehin schon als Fläche gemappt war.

Repariert.

On 22.09.2017 20:30, dktue wrote:

Hallo,

ich habe die Fälle nun bundesweit händisch und einzeln korrigiert, benötige aber Unterstützung für 
die letzten fünf verbliebenen Nodes [1].


Kann das mal jemand gegen prüfen und gegebenenfalls korrigieren?

Viele Grüße
Daniel

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



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

Re: [Talk-de] zwei ref´s an einer Bundesstraße

[Tom Pfeifer]

On 08.09.2017 10:39, Scholtes, Martin wrote:

Es ging mehr mehr drum, welche Quelle ist vertrauenswürdiger: Die hundert 
Leitpfosten mit einem ref oder ein,zwei Straßenschilder mit zwei ref ?


Wenn die zwei Bundesrouten ein Stück über das selbe Asphaltband geführt werden, muss sich das ja 
nicht zwangsläufig auf den Leitpfosten widerspiegeln. Die sind ja eher für die Notfallkommunikation 
oder Wartung gedacht.


Gegebenfalls kann man ja auch das Bundesfernstraßengesetz und die entsprechenden Widmungen der 
Straßen zu Rate ziehen, diese finden sich offenbar auch in den Amtsblättern der Länder, Beispiel [1].


[1] https://bravors.brandenburg.de/br2/sixcms/media.php/76/Amtsblatt%2038_06.pdf

tom

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

Re: [Talk-de] landuse=residential an Node

[Tom Pfeifer]

@Martin - er hatte eine Overpass-Abfrage beigelegt.

Ja, ich habe Einwände.
landuse=residential gibt es 5026x auf einer Node, im Vergleich zu 4,2 Mio 
Flächen.
Die Nodes sind weltweit verteilt.

All diese Nodes beinhalten die Aussage, dass sich dort ein Siedlungsgebiet 
befindet.
Für ein Löschen dieses Tags gibt es überhaupt keinen Grund, schon gar nicht "auf einen Rutsch" 
(=mechanical edit[1]).


Wenn du etwas verbessern möchtest, lade das Gebiet einer solchen Node, in einer Gegend, in der du 
den Bebauungs-Stil von Wohngebieten kennst und anhand des Luftbildes einschätzen kannst, und zeichne 
den Umriss des Wohngebiets. Die Node kannst du im Umring verwenden. [2]


https://wiki.openstreetmap.org/wiki/DE:Automated_edits
https://wiki.openstreetmap.org/wiki/DE:Good_practice#Erhalte_die_Chronik

On 07.09.2017 18:04, Scholtes, Martin wrote:

hast du ein Beispiel?
-Ursprüngliche Nachricht-
Von: dktue [mailto:em...@daniel-korn.de]
Gesendet: Donnerstag, 7. September 2017 11:03
ich habe bemerkt, dass es vereinzelt Nodes gibt an denen landuse=residential getaggt 
wurde [1]. Ich möchte gerne in einem Rutsch das Tag "landuse=residential" von 
diesen Nodes entfernen, aber dies vorher hier diskutieren.

Hat jemand Einwände?

Viele Grüße
dktue

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


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

Re: [Talk-de] Krankenhaus - Eingang

[Tom Pfeifer]

On 26.08.2017 12:14, Martin Koppenhoefer wrote:

On 23. Aug 2017, at 14:34, Markus  wrote:
Im Wiki steht, man solle das Gebäude bezeichnen mit:
http://wiki.openstreetmap.org/wiki/DE:Tag:amenity=hospital


ich würde das gesamte Krankenhaus damit taggen, z.B. wenn es mehrere Gebäude 
sind oder Aussenflächen dazugehören dann würde ich die in mein 
Krankenhauspolygon miteinschließen


+10, das Wiki war etwas diffus in der Rangfolge, sollte jetzt klarer sein.

tom

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

Re: [Talk-de] OSM-Karte mit anderer Projektion auf unteren Zoomstufen

[Tom Pfeifer]

On 07.07.2017 17:27, Frederik Ramm wrote:
[...]

ihrer Bachelor-Arbeit Gedanken darüber gemacht, ob man auf den unteren
Zoomstufen nicht eine andere Projektion einsetzen könnte. [...]
im Rahmen einer Bachelorthesis („Die WebMercator-Verzerrung: Prototyp
einer optimierten Weltkartendarstellung für Webkartendienste“) 


Coole Sache, habe bereits den survey positiv gemonkeyed.

Welche Projektion wurde denn nun verwendet?
Könnte ruhig noch eine Zoomstufe so weitergehen.
Vielleicht sollte man in der neuen Projektion, sowie in der ersten Mercator-Stufe, auch die 
Meridiane rendern, dann wird der Projektionswechsel auch dem Laien verständlicher.


tom

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

Re: [Talk-de] Massenedit bei living_street

[Tom Pfeifer]

Jeder Massenedit [1] bügelt über lokale Ausnahmen sowie mögliche vorhandene Fehler hinweg und ist 
daher vorher zu diskutieren und hat nach den Richtlinien [2] zu erfolgen.


Wenn der Nutzer unkooperativ ist, wird die DWG [3] informiert, der Nutzer wird geblockt und die 
Edits revertiert.


[1] https://wiki.openstreetmap.org/wiki/DE:Automated_edits
[2] https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct
[3] https://wiki.openstreetmap.org/wiki/DE:Data_working_group

Mögliche Ausnahmen sind hier lokale spezifische Geschwindigkeitsfestlegungen, mögliche Fehler z.B. 
Tempo-30-Zonen, die versehentlich als living_street getaggt wurden.


tom

On 23.05.2017 11:22, Stephan Martens wrote:

Hier z.B.: wurde eine Tempo-30 Zone bei der sogar die Schilderart DE:274.1 
(Tempo-30-Zone) katrografiert wurde zu maxspeed:walk
https://www.openstreetmap.org/way/305956789/history

Ist das Vandalismus Deutschlandweit?


Mit freundlichen Grüßen
Stephan
aka smarties




Gesendet: Dienstag, 23. Mai 2017 um 11:05 Uhr
Von: smart...@gmx-topmail.de
An: talk-de@openstreetmap.org
Betreff: [Talk-de] Massenedit bei living_street

Hallo,

was sagt Ihr dazu das der User:Graf Westerholt in ganz Deutschland bei mehreren 
zehntausenden living_street ein maxspeed:walk setzt, egal ob da vorher ein 
maxspeed:30, 7 oder garnichts dranstand? Er ist da auch schon reichlich mit 
anderen Usern zusammengestoßen und weigert sich sein tun aufzugeben. Ca. 10% 
seiner Changesets wurden auch bereits komplett zurückgesetzt, er macht aber 
munter weiter.

Es gibt ein Proposal zu maxspeed:walk das allerdings 2008 (vor 9 Jahren) nicht 
zu Ende geführt wurde (ja eigentlich noch nicht mal richtig angefangen wurde). 
http://wiki.openstreetmap.org/wiki/Proposed_features/maxspeed_walk

Ich habe Ihn angeschrieben, er meint jede Zahl wäre falsch und nur "walk" wäre 
richtig und er höre nicht damit nicht auf.


https://www.openstreetmap.org/changeset/47980360
https://www.openstreetmap.org/changeset/47980908
https://www.openstreetmap.org/changeset/47980016
https://www.openstreetmap.org/changeset/47978442
https://www.openstreetmap.org/changeset/47977546



Mit freundlichen Grüßen
Stephan
aka smarties



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

Re: [Talk-de] Geschwindigkeitsbegrenzungen protokollieren

[Tom Pfeifer]

Ich glaube, das weiß Flo, es ging ihm wohl mehr um das Erfassen als das Mappen.

Beim Erzeugen von Wegpunkten in einem GNSS-Logger sollte man auch den 'time lag' im Gerät 
berücksichtigen, wenn man selbst in Bewegung ist.
Wenn man beim Passieren eines Schildes den Knopf drückt, zeichnet das Gerät eine bereits vom 
Prozessor verarbeitete Position auf, diese liegt dann typischerweise 5-50 m vor dem Schild.


Macht man das aus beiden Fahrtrichtungen z.B. an einem Ortsschild, kann man den Wert in der Mitte 
nehmen. Bei asymmetrischen Beschränkungen wird das halt schwierig, auch weil man nur die Rückseite 
sieht.


tom

On 22.05.2017 11:15, Toni Erdmann wrote:

Für unterschiedliche Werte pro Richtung gibt es z.B.

maxspeed:forward=60   und
maxspeed:backward=100

Am 22. Mai 2017 10:52:01 MESZ schrieb Florian Lohoff :


Ich sehe die Schilder zu taggen als ganz großes Hilfsmittel
zwischen den Mappern zu kommunizieren. Und nach meiner Erfahrung
ist es nahezu unmöglich asymmetrische Geschwindigkeitsbeschränkungen,
d.h. je Fahrtrichtung unterschiedlich, ohne die Schildpositionen
zu mappen.


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

Re: [Talk-de] Liste mit Händleradressen hinzufügen

[Tom Pfeifer]

On 12.04.2017 11:46, Martin Trautmann wrote:

wie kann ich am einfachsten eine Liste von Händlern hinzufügen?


Kurze Antwort: tu es nicht.


Konkretes Beispiel: hier in Freiburg haben sie die Gasabfüllstation am 
Güterbahnhofgelände
abgerissen.


Die abgerissene Station darft du in OSM löschen, gib im Changeset-Kommentar bitte an, was wann 
passiert damit ist.



Damit ist auch der dortige Händler verschwunden. Jetzt gibt es nur noch die 
Baumärkte
als naheliegende Bezugsquelle.


Wenn du im konkreten Baumarkt gesehen hast, dass dort abgefüllt wird, kannst du 
das einzeln eintragen.


Auf www.basigas.de fand ich aber eine ganze Händlerliste. Wie kann ich deren 
Informationen nun unter
der Kategorie Flüssiggas am einfachsten der openstreetmap hinzufügen?


Die dortige Liste (http://www.basigas.de/kontakt/gasecenter.php) wurde vom Betreiber der Webseite 
für seine Zwecke zusammengestellt, und ist mit dem Vermerk "Copyright 2017" gekennzeichnet. Damit 
hat sie der Seitenbetreiber nicht unter eine freie Datenbanklizenz gestellt, man darf nicht einfach 
dahergehen, die Liste kopieren und in eine andere Datenbank (hier OSM) einpflegen. Kurz, die Lizenz 
ist nicht mit der ODbL [1] kompatibel.



Zur besseren Verarbeitung habe ich sie bereits in eine Tabelle übertragen:



Das solltest du wieder löschen, da du bereits hier ein fremdes Werk kopiert und zur Verbreitung im 
Internet bereitgestellt hast. Es sei denn, du hast eine schriftliche Erlaubnis des Urhebers, dies zu 
tun.


Des weiteren wäre das Einpflegen einer solchen Liste ein Import, für den in OSM strenge Maßstäbe 
gelten. [2]


Schließlich haben solche Listen erfahrungsgemäß viele Fehler. 5% der Firmen wurden geschlossen, 5% 
habe andere Öffnungszeiten, 5% sind umgezogen, 5% wurden von einer Kette geschluckt, und ein paar 
Adressen waren schon bei der Eingabe fehlerhaft. OSM will solche Daten daher vor Ort erfassen, da 
machen wir nur unsere eigenen Fehler.


Was du also machen kannst, du packst dir die Liste in deine Satteltasche, und wenn du an einer 
solchen Station vorbeireitest, prüfst du die Daten und trägst dann diese Station ein.


[1] https://wiki.openstreetmap.org/wiki/Open_Database_License
[2] https://wiki.openstreetmap.org/wiki/Import

Viele Grüsse
Tom

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

Re: [Talk-de] Ankündigung der Entfernung von landuse =farm im Standardstil

[Tom Pfeifer]

On 23.03.2017 14:20, Stefan Martinek wrote:

Hy hab da als Neuling eine blöde Frage: Also gehören jetzt hier nur die rot
gekennzeichneten Felder von =farm auf =farmland oder =farmyard umgestellt?


Gute Frage, richtige Frage!

Ja so sieht das aus. Und was von beiden es ist, oder vielleicht inzwischen mit einer Siedlung 
bebaut, solltest du mit Ortskenntnis, oder mindestens mit einem aktuellen Luftbild entscheiden, und 
nicht nur der Grösse nach vermuten.



Am 23. März 2017 um 13:45 schrieb Walter Nordmann :

Die Farben dürften klar sein, ich empfehle als Hintergrund OSM Gray und
hab das auch voreingestellt.


Kurioserweise sehe ich beim Nachladen von Kacheln immer erst farbige, die dann zu Grau mutieren. In 
der Page-Info sehe ich nur die grauen Kacheln.



Der Lag der Live-DB wird unten rechts angezeigt und beträgt normalerweise
1-2 Minuten.


tickt bei mir etwas wie 04:39:14

vg Tom


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

Re: [Talk-de] Wie am besten Uploaden

[Tom Pfeifer]

On 8 Mar 2017, at 06:41, Stefan Martinek  wrote:

Ich meine sollte man eher jede kleine Änderung einzeln
hochladen oder doch zusammenwarten und grosse Pakete hochladen? Wie kommen
die Server damit zurecht beim rendern und einpflegen? Wie macht ihr das so?


On 08.03.2017 10:04, Martin Koppenhoefer wrote:

für die Server spielt es keine so große Rolle, aber für die Nachvollziehbarkeit 
durch andere Mapper ist es m.E. besser, kleinere Änderungssätze zu machen, die 
am Besten thematisch zusammengehören (mit passendem Changeset Kommentar was Du 
und ggf. weshalb Du es gemacht hast). Außerdem verringerst Du dadurch die 
Wahrscheinlichkeit von Konflikten und kannst letztere falls sie doch auftreten 
einfacher lösen (Konflikte gibt es, wenn andere Mapper gleichzeitig wie Du 
dieselben Objekte ändern).



Der thematische Zusammenhang ist auch für Korrekturmöglichkeiten sinnvoll.

Wenn ich zweihundert Häuser zeichne, geht dabei wenig schief.

Wenn ich z.B. eine Grenz- oder Nahverkehrsrelation anfasse, mir ein 
Fehler unterläuft, und das Changeset revertiert werden muss, ist es gut, 
diese kompliziertere Arbeit separat hochgeladen zu haben, auch wenn es 
"nur" die eine Relation ist, dann sind beim Revert nicht die 200 Häuser 
futsch.


tom


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

Re: [Talk-de] Entfernen von wheelchair_toilet Tags

[Tom Pfeifer]

Ich hatte den Thread damals angestossen, und stimme mit Holger überein, 
dass sich das sauber mit overpass-Abfragen und JOSM lösen lässt.


Das Konzept, das sich seitdem bei mir geformt hat, sähe vor, die 
verschiedenen Fälle vorzusortieren (gleichlautende, widersprüchliche, 
unknown) und dann schrittweise umzuwandeln.


Die Ursache waren ja nicht, wie in anderen Fällen, veraltete Tags oder 
verschiedene Meinungen von Mappern, sondern ein Softwarebug. Ich kann 
mir bei Tageslicht nochmal die Verteilung der Tags anschauen und eine 
Reihenfolge vorschlagen.


tom

On 21.02.2017 20:20, Holger Jeromin wrote:

Jan Schulte  Wrote in message:

Hallo talk-de,

ich bin Jan und arbeite derzeit an der wheelmap. Derzeit kümmern wir uns
darum, POIs zu bereinigen, die das wheelchair_toilet Tag haben. Ich habe
bereits diesen Thread gelesen
https://lists.openstreetmap.org/pipermail/talk-de/2016-July/113238.html
wo das Thema diskutiert wurde. Wir haben uns bereits Gedanken gemacht,
wie wir diese POIs in der wheelmap selbst bereinigen
(https://github.com/sozialhelden/wheelmap/issues/400). Im Thread wurde
empfohlen, dies in OpenStreetMap über einen Mechanical Edit zu lösen.
Bevor wir dies starten, möchten wir nachfragen, ob das immer noch
gewünscht ist. Falls ja, dann würden wir unsere Migration so anpassen,
dass sie die Änderungen via Rosemary auch direkt an die OpenStreetMap
überträgt.

Was denkt ihr dazu?



Ich bin immer noch dafür das in OSM anzupassen. Danke dass du das
 nochmal ansprichst und auch machen willst.


Wobei ich mich frage ob das über rosemary ein schlauer Weg ist.
 Ich würde es eher mit JOSM machen. Da habe ich das Gefühl, dass
 man das fehlerfreier reinbekommt als über eine Zusatzfunktion bei
 euch.





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

Re: [Talk-de] Da ist mir etwas aufgefallen

[Tom Pfeifer]

Ist behoben. Das war wohl versehentlich hochgeladen worden. Auf 
vermutlich der gleichen Mappingparty war wohl auch noch ein anderer User 
mit dem gleichen Problem.


Das erste liess sich schnell mit dem JOSM-reverter beheben, beim zweiten 
waren aber auch noch sinnvolle Edits drin, so dass man selektiv löschen 
musste, und aufpassen nicht die Null-Boje zu erwischen :-)


Gruesse
Tom

On 15.02.2017 08:42, gmbo wrote:

Bin gerade über den Änderungssatz eines neuen Benutzers gestolpert.
Sieht aus wie Tests an Pos 0/0
https://www.openstreetmap.org/changeset/46097003#map=13/-0.0349/0.0334

User: faisalhandal87

vor 19 Std.  angemeldet

MASIH ADA KESALAHAN
ES GIBT IMMER NOCH FEHLER

ist da in Malaisch angegeben.



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

Re: [Talk-de] Fussgänger Routing durch Anlagen in denen Eintritt verlangt wird.

[Tom Pfeifer]

On 09.02.2017 15:05, Martin Koppenhoefer wrote:

Am 9. Februar 2017 um 14:57 schrieb chris66 :


Ein Router kann nicht feststellen auf welcher Seite des Nodes
das fee=yes gilt.


ist ja auch egal, das Passieren des nodes kostet.


Oder wenn der Themenpark als Polygon fee=yes hat, könnte der Router das 
auswerten. Das hilft auch bei der Richtungsbestimmung.


Apropos Drehkreuze, es gibt doch entrance=exit und entrance=emergency,
beide spezifizieren einen richtungsabhängigen Ausgang aus einem Polygon.

tom


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

Re: [Talk-de] Quelle von GPX-Track finden

[Tom Pfeifer]

On 31.01.2017 09:14, Markus wrote:

Wie kann ich den Ersteller eines GPX-Tracks finden?
Track wird in JOSM angezeigt als "GPS-Rohdaten".


Das hängt sicher von der privacy-Einstellungen des Tracks ab.

Im Layer-Fenster erscheint "Downloaded GPX Data", dort, rechte 
Maustaste, siehst du ein Trichtersymbol "Choose visible tracks". Das 
öffnet eine Tabelle mit den Details der geladenen Tracks, u.a. die URL 
mit dem Usernamen drin. Falls der Track öffentlich ist.


Hier kannst du auch nach einem Zeitfenster filtern, praktisch bei neu 
gebauten Kreisverkehren.


Ausserdem kannst du das InfoMode-Plugin installieren, da bekommst du 
links ein Tracksymbol mit "info", wenn du das aktivierst siehst du die 
Details auch mit Mouseover auf den _Punkten_ im Hauptfenster.

https://wiki.openstreetmap.org/wiki/JOSM/Plugins/InfoMode

tom

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

Re: [Talk-de] Mitteldeutsche Schleife -> reg_name ?

[Tom Pfeifer]

Tom Pfeifer wrote on 2016/09/07 18:57:

Martin Koppenhoefer wrote on 2016/09/07 12:02:

name auf dem highway Objekt oder auf der Route Relation? M.E. gehört sowas wie 
Berliner Ring eher in eine Route Relation, weil es sich ja z.B. mit Berliner 
Ring überlappt.



Mitteldeutsche Schleife:

Keine eigene Routenrelation
Highway-Segmente:
name=Mitteldeutsche Schleife, gesetzt von SennaHB, Nov 2015
auf den Teilstücken der A14, A9, A38, A143
A 38 auch mit reg_name=Südharzautobahn
A143 stückweise reg_name=Westumfahrung Halle


Es gibt jetzt eine Route:
https://www.openstreetmap.org/relation/6572024

War ziemlich fummelig, spannenderweise trugen keine der Brücken bzw.
Tunnelprojekte den Namen, und die Relation lässt sich natürlich nicht
fix mal automatisch als Rundroute sortieren.

Damit ist die Schleife jetzt als Einzelobjekt auffindbar.

"loc_name" ist auf allen Einzelsegmenten noch unbelegt
(Teile der A38 und A143 belegen bereits "reg_name"),

Nächster Plan wäre, "name" auf den Segmenten auf
"loc_name" zu ändern bzw. wo es fehlt anzulegen.

Oder nur "name" von den Einzelsegmenten entfernen...

tom

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

Re: [Talk-de] Mitteldeutsche Schleife -> reg_name ?

[Tom Pfeifer]

Martin Koppenhoefer wrote on 2016/09/07 12:02:

name auf dem highway Objekt oder auf der Route Relation? M.E. gehört sowas wie 
Berliner Ring eher in eine Route Relation, weil es sich ja z.B. mit Berliner 
Ring überlappt.


Status quo:

Berliner Ring:
==
Routenrelation 5485500, name=Bundesautobahn 10, ref=A 10
Highway-Segmente:
name=Östlicher...etc Berliner Ring
reg_name=Berliner Ring

AVUS:
=
Teilstrecke der Routenrelation 5485765, name=Bundesautobahn 115, ref=A 115
Highway-Segmente:
name=AVUS (auf dem relevanten Teilstück)

Autobahn der Freiheit:
==
Routenrelation 548, name=Bundesautobahn 12, ref=A 12
Highway-Segmente:
name=Autobahn der Freiheit, gesetzt von miko101
Wikipedia: Ehrenname "Autobahn der Freiheit", seit 9. Okt 2014

Mitteldeutsche Schleife:

Keine eigene Routenrelation
Highway-Segmente:
name=Mitteldeutsche Schleife, gesetzt von SennaHB, Nov 2015
auf den Teilstücken der A14, A9, A38, A143
A 38 auch mit reg_name=Südharzautobahn
A143 stückweise reg_name=Westumfahrung Halle


Am sinnvollsten scheint mir eine Routenrelation für die Schleife, die im
Gegensatz zu den anderen Beispielen keinen Streckencharakter hat. Das
kollidiert dann auch nicht mit den streckenbezogenen reg_name der A38/A143.


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

Re: [Talk-de] Liegenschaften des Bundesnachrichtendienstes

[Tom Pfeifer]

Martin Koppenhoefer wrote on 2016/09/06 07:56:

Il giorno 06 set 2016, alle ore 00:56, Tom Pfeifer  ha scritto:

Wenn es denn eine Regierungsbehörde ist:
Es gibt ja die noch offenen Diskussionen im Bereich
- landuse=civic_admin
- landuse=institutional



ich fände es besser, etwas spezifischer zu taggen, damit man auch semantisch 
suchen kann und nicht nur über den Namen. So was wie 
amenity=intelligence_service


Ja bitte, das ist dann die Einrichtung, nicht die Landnutzung.
Trag doch die Idee zur Tagging-Liste.

tom


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

Re: [Talk-de] Liegenschaften des Bundesnachrichtendienstes

[Tom Pfeifer]

Martin Koppenhoefer wrote on 2016/09/02 22:48:

Mir ist beim Lesen dieses Artikels  der mit einer OSM Karte illustriert ist

> [...] zufällig aufgefallen, dass die Liegenschaften des BND den tag 
landuse=military tragen.
> Das ist vermutlich nicht korrekt, da es sich beim BND um eine nachgeordnete 
Behörde des
> Bundeskanzleramtes handelt, und keinesfalls um eine militärische Einrichtung.
> Der militärische Nachrichtendienst ist der MAD.


Z.B. hier:
http://www.openstreetmap.org/way/239950443

Wie könnte man das besser taggen?


Wenn es denn eine Regierungsbehörde ist:
Es gibt ja die noch offenen Diskussionen im Bereich
- landuse=civic_admin
- landuse=institutional

https://wiki.openstreetmap.org/wiki/Proposed_features/Civic_admin
https://wiki.openstreetmap.org/wiki/Tag:landuse%3Dinstitutional

wobei wohl jemand ersteres grade zementieren will:
- https://wiki.openstreetmap.org/wiki/Tag:landuse%3Dcivic_admin

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

Re: [Talk-de] Mitteldeutsche Schleife -> reg_name ?

[Tom Pfeifer]

"Christian Müller" wrote on 2016/09/05 23:23 + 2016/09/06 00:00

Von: "Tom Pfeifer"
Daher plädiere ich dafür, das Tagging mit dieser Bezeichnung in
reg_name oder loc_name [4] zu überführen, da ich es für einen
regional und nicht allgemein genutzten Namen halte.


Da schieben wir doch am besten gleich die regionalen
Bezeichnungen in anderen Ländern ebenfalls in reg_name
und schreiben brav die deutschen Namen als die allgemein
Benutzten hinein.  Klar, das wir dazu allgemein deutsche
Quellen anführen und die regional fremdländischen brav
ignorieren.


> Da der Verkehrsfunk [...] Ein "allgemeiner Name" lässt
> sich mit seiner Hilfe weder nachweisen noch widerlegen.

Danke dass du die Diskussion aufnimmst.

Der Ironie kann ich aber nur bedingt folgen. Für deutschsprachige Namen
im Ausland gibt es name:de, darum geht es hier nicht.

Vielmehr wollte ich sondieren, ob die Bezeichnung, wenn sie schon
nicht ausgeschildert wurde, wenigstens allgemeiner Sprachgebrauch ist.

Die von dir zitierten Dokumente stützen aber eher das Gegenteil,
es erscheint als eine Meinung eines ehemaligen Verkehrsministers und eine
Radio-PR-Aktion, alles im Jahre 2003, und gelegentlich taucht die
Bezeichnung noch in Gänsefüsschen in politischen Dokumenten zum
Weiterbau der A143 auf.

Der Berliner Fernsehturm sollte auch mal unbedingt "Telespargel" genannt
werden, sagte und sagt aber keiner.

Also machen wir die Gegenprobe:

- Wenn du jemand von Grimma nach Löbejün zum Klettern lotst, empfiehlst
  du ihm "Nimm die Nördliche Mitteldeutsche Schleife" oder "Fahr die A14"?

- Möchtest du, dass dir dein Navi am Schkeuditzer Kreuz empfiehlt,
  "Biege jetzt ab auf die Mitteldeutsche Schleife"? Wohin fährst du dann?

Mangels Fertigstellung der A143 ist die Schleife ja noch nicht mal eine.

Mit einer Routenrelation könnte ich mich ja noch anfreunden, aber
auf den Einzelautobahnen finde ich es irritierend.

tom


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

[Talk-de] Mitteldeutsche Schleife -> reg_name ?

[Tom Pfeifer]

Beim Befahren der A9 Berlin-München fiel mir im Bereich Halle/Leipzig
in OSM das Tagging name=Mitteldeutsche Schleife für Teile der A9/14/38/143 auf.

Laut Wikipedia [1] entstand dieser Name als Hörer-Wettbewerb eines
Radiosenders.

Eine Beschilderung mit diesem Namen habe ich bisher nicht gefunden,
auch kein offizielles Dokument, in dem er erwähnt wird. Auch im
Verkehrsfunk ist habe ich die Bezeichnung nicht gehört, im Gegensatz
z.B. zum Berliner Ring.

Reiseführer und selbst andere Wikipediaartikel sprechen von der
"sogenannten Mitteldeutschen Schleife".

Daher plädiere ich dafür, das Tagging mit dieser Bezeichnung in
reg_name oder loc_name [4] zu überführen, da ich es für einen
regional und nicht allgemein genutzten Namen halte.

Anderenfalls bitte ich um das Aufzeigen von Quellen, die einen
offiziellen Charakter dieses Namens belegen.

[1] https://de.wikipedia.org/wiki/Mitteldeutsche_Schleife
[2] Bernd Görne: Baedeker Reiseführer Leipzig, Halle, 2015, S. 26
[3] https://de.wikipedia.org/wiki/Bundesautobahn_143
[4] https://wiki.openstreetmap.org/wiki/DE:Key:name

tom



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

Re: [Talk-de] Help needed for mapping missing navigation data in Germany

[Tom Pfeifer]

Nikhil,
thanks for discussion your remote mapping plans in advance.

However, what I miss from the analysis on your diary page is the
analysis how much in need the named cities are for a remote mapping
approach, i.e. when you count existing turn restriction, what is your
estimate of missing ones or wrong ones?

My guess is that there are very few missing in Berlin, and the motorways
are quite complete with exit numbers and destination tagging.

Berlin is well covered with local mappers who are quite responsive to
constant changes in restrictions, lane layout and construction sites.
Relying mostly on mapillary, which covers about 3 years now, you would
get in trouble with these things having changed meanwhile.

tom

Nikhil Prabhakar wrote on 2016/08/12 14:33:

Hello Everyone,

In an effort to improve the navigation data in Europe, we are planning to
add/verify turn restrictions, exit numbers and destination names in the
cities of Europe starting with Berlin, Stuttgart and Wolfsburg in Germany.
We will be using Mapillary images as a source for adding these data. We
have shared our initial analysis, workflow and tagging system we are going
to follow in OSM diary[1]. We would like your support and involvement in
this endeavour and also, it would be great to hear about any questions or
feedbacks that you all may have regarding the workflow and tagging system
that we are following before taking this forward.

[1] Diary post - http://www.openstreetmap.org/user/nammala/diary/39255



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

Re: [OSM-talk-ie] pokestops

[Tom Pfeifer]

Rory McCann wrote on 2016/07/25 15:52:

On 25/07/16 15:45, os...@tutanota.com wrote:

With an "We've all been there" follow up question. When you say
delete them, do you mean just go in and select the nodes and delete
or is there a better way to handle it?


You can just delete the nodes, yes. In theory you could do a revert of
the changeset, but TBH it's a small changeset, so it'd be quicker to
just manually delete it. It'll appear the same in the database.


Well, this case contained 7 new and one modified object, in which a
real memorial was renamed. Thus simply deleting them would have
destroyed this one.

Reverted meanwhile.

tom


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

Re: [Talk-de] Mobile Verkaufsstände

[Tom Pfeifer]

Martin Koppenhoefer wrote on 2016/07/14 14:19:

Dass intermittent ...

ich hätte das gerne etwas granularer. Es ist schon ein ziemlicher
Unterschied, ob da ein Weihnachtsmarktstand gemappt ist, der 1 Woche im


Für Weihnachtsmärkte/bäume gibt es doch schon ein Tagging, und
sogar eine Weihnachtsmarktkarte?

Vielleicht kann man das aufgreifen? Mir fehlt grad die Zeit zum Nachlesen.

tom


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

Re: [Talk-de] Mobile Verkaufsstände

[Tom Pfeifer]

Sven Geggus wrote on 2016/07/14 10:02:

Das bedeutet wenn man das nicht rendern möchte, dann braucht man eine
Postgresql funktion die opening_hours parsen kann?!  Dann doch besser
intermittent.

Der Unterschied zu Wochenmärkten ist, dass die ihr eigenes Tag
amenity=marketplace haben, das derzeit gar nicht gerendert wird.


Es spricht doch nichts dagegen, beide Tags zu verwenden,
opening_hours und intermittent.

Dass intermittent schon für Wasserwege benutzt wird, ist ja auch kein
Hindernis. Ich nehme capacity ja auch für Fahrradstellplätze und Kindergärten.

Und schon kann man den Burger gestrichelt zeichnen ;-)

tom


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

Re: [Talk-de] Skandal! Skulptur im Park ohne rollstuhlgerechte Toilette!

[Tom Pfeifer]

Holger Jeromin wrote on 2016/07/09 08:19:

Tom Pfeifer <t.pfei...@computer.org> Wrote in message:

Dazu kommt noch ein neuer Tag 'wheelchair_toilet=*' (4600x), hier gibt es mehr
'unknown' als 'yes' und 'no' zusammen (53%). Undokumentiert.


Das falsche Tag war mir auch schon mal aufgefallen und habe es den
  sozialhelden gemeldet. Daraufhin haben sie den Fehler im backend
  innerhalb von wenigen Tagen behoben. Das ganze ist ein zwei Jahre
  her.

Neue sollten nicht mehr rein kommen. Ich wäre für einen mechanical
  edit zur Korrektur.


Danke Holger für den Hinweis, ich habe daraufhin mal das Zeitverhalten
analysiert:

Über den Sammeluser 'wheelmap_android' kamen noch bis vor 7 Monaten
die 'wheelchair_toilet' herein. In jüngeren Changesets nicht mehr,
allerdings wird dann zusätzlich ein 'toilets:wheelchair' aufgeklebt,
ohne das alte zu löschen.

'unknown'-Werte sind mir in jüngeren Changesets auch nicht mehr aufgefallen.
Leider sieht man den Fix nicht an der Softwareversion, alt wie neu kommt mit
'rosemary v0.4.4'.

Für einen mechanischen Edit wäre ich auch, insbesondere da der fehlerhafte
Key nun auch von anderen Mappern übernommen wird.

Kriterien wären aus meiner Sicht:
- Löschen von {wheelchair_toilet|toilets:wheelchair}=unknown
- Wenn beide vorhanden sind, vergleichen, bei Gleichheit wheelchair_toilet 
löschen
- bei Ungleichheit die Anzahl ermitteln, ob man sich die einzeln ansehen kann,
  ggf. den zeitlich neueren Wert übernehmen, meist wird das toilets:wheelchair 
sein
- wenn nur wheelchair_toilet={yes|no} vorhanden, auf toilets:wheelchair ändern
- verbleibende Werte ausserhalb von {yes|no} manuell prüfen.

Unschön bleiben noch das mehrfache Hochzählen der Versionsnummern im
gleichen CS für jeden geänderten Tag, und das *toilet*=no an Objekten,
an denen man ohnehin keine Toilette erwartet, z.B.

amenity=drinking_water
highway=bus_stop
natural=cave_entrance
historic=memorial
tourism=artwork

tom

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

[Talk-de] Skandal! Skulptur im Park ohne rollstuhlgerechte Toilette!

[Tom Pfeifer]

Vermutlich bin ich ja politisch völlig inkorrekt, aber ich finde es
eigentlich ganz gut, dass eine Skulptur im Park keine rollstuhlgerechte
Toilette aufweist.

https://www.openstreetmap.org/node/258485628
tourism=artwork
artwork_type=sculpture
wheelchair=no
toilets:wheelchair=no

Warum sie mit Rollstuhl nicht zugänglich ist, kann ich angesichts eines
vorbeiführenden Fuss/Radweges nicht ganz nachvollziehen.

Das ist nur ein Beispiel, aber ich finde es befremdlich, an was für
unplausiblen Objekten immer mehr solche Tags aus der Wheelmap auftauchen.

Bushaltestellen und Supermarktparkplätze pflegen insgesamt wenig Toiletten
zu haben, dann natürlich auch keine für wheelchair.

Auch hat toilets:wheelchair fast 4000x den Wert 'unknown' (10%) [1],
kann man das nicht weglassen? Steht auch so im Wiki [3].

Dazu kommt noch ein neuer Tag 'wheelchair_toilet=*' (4600x), hier gibt es mehr
'unknown' als 'yes' und 'no' zusammen (53%). Undokumentiert.

Liest ein Sozialheld hier mit? Hochachtung für das Projekt als solches,
mir geht es um die technischen Details, die Vereinheitlichung des Taggings,
und die sinnvolle Steuerung des Mappings.

Sollten wir aufräumen wollen, dann gibt es noch recht häufig
'wheelchair:toilets=*' (472x) [4], vorwiegend im Ruhrgebiet offenbar aufgrund
eines alten Imports aus ruhr2010-barrierefrei.de und dessen Abfärbungen,
undokumentiert.

[1] https://taginfo.openstreetmap.org/keys/toilets%3Awheelchair#values
[2] https://taginfo.openstreetmap.org/keys/wheelchair_toilet#values
[3] https://wiki.openstreetmap.org/wiki/Key:toilets:wheelchair
[4] https://taginfo.openstreetmap.org/keys/wheelchair%3Atoilets

tom

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

Re: [Talk-de] place=square

[Tom Pfeifer]

Florian Lohoff wrote on 2016/06/28+29

Entsprechend brauchen dann Adressen an dem Platz auch kein addr:street
sondern addr:place.


Ich befand mich bei meiner Kritik an addr:place im Irrtum, es handele sich
um einen neuen Vorschlag. addr:place ist aber 5.5 Mio mal im Einsatz,
etwa 10% von addr:street 56 Mio. Alles gut.

> Und was ist wenn es eine Straße und ein Place gibt die gleich heissen?

Ja, was empfehlen wir insbesondere wenn es den Schlossplatz gibt, der
auch von einem highway=* durchzogen wird, der auch mit Schlossplatz
beschildert ist?

addr:place oder addr:street an die Häuser?

(Als konkretes Beispiel hätte ich den Molkenmarkt in Berlin zu bieten.)

tom



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

Re: [Talk-de] place=square

[Tom Pfeifer]

Florian Lohoff wrote on 2016/06/28 14:04:

Falsch - addr:street brauch dann eine Straße die so heisst in der Nähe.
Wenn es keine gibt dann funktioniert die Adresse nicht weil Nominatim
keine Hierarchie bauen kann.

Deshalb - place node anlegen für den Platz und auf den Adressen die
dazu gehören entsprechend das addr:street zu einem addr:place machen.
Dann ordnet Nominatim the Adresse einem entsprechenden place node
zu.

http://nominatim.openstreetmap.org/details.php?place_id=123389138


Dann sollte doch besser Nominatim lernen, dass es ein addr:street
auch einem place=square zuordnen kann, als allen neuen Mappern beizubringen,
dass sie den Schlossplatz 27 mit einem anderen Adresstag mappen müssen
als die Schlossstrasse 47 ?

tom


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

Re: [Talk-de] place=square

[Tom Pfeifer]

Florian Lohoff wrote on 2016/06/28 12:35:

On Tue, Jun 28, 2016 at 11:25:27AM +0200, Martin Koppenhoefer wrote:

http://wiki.openstreetmap.org/wiki/Tag:place%3Dsquare


Entsprechend brauchen dann Adressen an dem Platz auch kein addr:street
sondern addr:place.


Der Platz selbst braucht kein Adresstag, so wie eine Straße ja auch
kein addr:street bekommt, sondern die angrenzenden Häuser.

Für die Häuser reicht auch addr:street=Alexanderplatz, da brauche ich
auch kein extra Tag dafür.


Leider wird der Name nicht gerendert -


Daher ja Martins Werbung, wenn mehr Tags benutzt werden, kommt auch der
Renderer vorbei

tom

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

Re: [Talk-de] breite Wassergräben

[Tom Pfeifer]

Lilienthaler wrote on 2016/06/22 13:53:

Manuel Reimer wrote

Folglich fände ich "Drain" für einen breiten Abwassergraben nicht ganz
falsch.


Es ist aber kein Abwasser, es sind Meliorationsgräben, die eine Niederung
entwässern. Deshalb finde ich ditch doch passender.


"Drain" heisst ja auch nicht Abwasser, sondern in diesem Kontext 
(Langenscheidt):

- als Verb:
  Land entwässern, dränieren, trockenlegen
  drain off, drain away: (Ab)Wasser etc. ableiten, -führen, -ziehen
  kanalisieren;
- als Substantiv
  Ableitung f, Abfluss
  Abflussrohr n, Abzugskanal m, Entwässerungsgraben m; Gosse
  Kanalisation

Das passt sehr wohl für Melioration.

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

Re: [Talk-de] das Buch von J. Bennett über OSM heute kostenlos als eBook

[Tom Pfeifer]

Martin Koppenhoefer wrote on 2016/06/07:
> Rückmeldung hierzu gerne

"Der Vollständigkeit halber" ist diese Information sicher relevant.


ja, hätte ich wahrscheinlich dazuschreiben sollen, der Preis ist es eine Email 
Adresse,

> wobei die ja nicht echt sein muss, falls man packt publishing nicht gut 
findet.

Wegwerfadressen gibt es an jeder 2. Ecke ;-)


anonbox wurde als invalid abgelehnt, ein bei einem Freemailer erzeugte
Wegwerfadresse angenommen (und musste auch nicht mal bestätigt werden).

Unklar sind die Lizenzbestimmungen, ob ich den freien content nun auch
weiterverteilen darf (das hängt davon ab, wo ich das Komma in den T setze). 
Wenn sie
aber nur alte Schinken als free raushauen, ist das dann auch wieder 
uninteressant.

vg tom


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

Re: [Talk-de] massenhaftes Löschen von Adressknoten / Tags auf Umringe

[Tom Pfeifer]

chris66 wrote on 2016/05/12 11:50:

Wurden die Formalien für einen mechanical Edit eingehalten?


Habe keinerlei Ankündigung oder Diskussion gefunden, weder auf talk-de,
der Berliner Liste noch im Forum.

Nicht einmal die Changesets selbst haben einen Kommentar, auch die
Quelle für die geometrischen Korrekturen fehlt.


Am 11.05.2016 um 19:04 schrieb Tom Pfeifer:

Mir ist ein Mapper aufgefallen, der grossflächig durch die Lande reitet
und jeweils im Tausenderpack Addressknoten löscht und deren Inhalt auf
Gebäudeumringe legt.

Aus meiner Sicht sind sowohl Einzelknoten als auch Taggen des Umrings
gebräuchliche Mappingstile, die kein grossflächiges Umtaggen erfordern.




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

[Talk-de] massenhaftes Löschen von Adressknoten / Tags auf Umringe

[Tom Pfeifer]

Mir ist ein Mapper aufgefallen, der grossflächig durch die Lande reitet
und jeweils im Tausenderpack Addressknoten löscht und deren Inhalt auf
Gebäudeumringe legt.

Aus meiner Sicht sind sowohl Einzelknoten als auch Taggen des Umrings
gebräuchliche Mappingstile, die kein grossflächiges Umtaggen erfordern.

Nebenbei geht die Historie der Objekte verloren, und es wird im konkreten
Fall offenbar nicht geprüft, ob betroffene Geschäfte und Büros tatsächlich
das Gebäude ausfüllen und nicht nur einen Raum.

Auch wenn die Edits vermutlich mit Sichtkontrolle eines Luftbildes erfolgen
und wohl auch Geometrien korrigiert und Umringe hinzugefügt werden, hat
die ganze Vorgehensweise Merkmale eines mechanischen Edits.

Mich interessiert eure Meinung dazu, man starte die Betrachtung bei
CS 39039628.

Tom

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

Re: [Talk-de] Neuer User, der viel loescht und auf Nachfrage nicht reagiert

[Tom Pfeifer]

Fazit: Die Löschungen sind nun revertiert, und Markus schaut sich
die Existenz der Pfade gelegentlich vor Ort im Wald an.



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

Re: [Talk-de] Neuer User, der viel loescht und auf Nachfrage nicht reagiert

[Tom Pfeifer]

Ich bin jetzt alle 13 CSs mit Achavi und JOSM durchgegangen,
sie sind weitgehend plausibel und korrekt bzw. korrigiert.
Im allerersten ist noch eine einzelne unbegründete Weglöschung.

Tom Pfeifer wrote on 2016/04/17 19:50:


Sollte unsere Diskussion zu einem Revert führen, dann wäre das derzeit
konfliktfrei möglich wenn man alle 3 CS zugleich lädt.


Ich bin dort für einen Revert, wer macht es?

tom


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

Re: [Talk-de] Neuer User, der viel loescht und auf Nachfrage nicht reagiert

[Tom Pfeifer]

malenki wrote on 2016/04/17 17:36:

malenki schrieb:


Die massiven Löschungen betreffen nur Pfade in einem begrenzten
Waldgebiet.


Die Dichte der Pfade ist sicher recht hoch, aber ich kann etliche
von ihnen an Waldrändern bzw. Schneisenmustern im Baumbestand auf
Bing erkennen. Öffentliche GPS-Traces haben sie leider nicht.

Eine solche Menge Trampelpfade ist in einem gut von Spaziergängern
heimgesuchten Wald aber durchaus möglich.

Eine Löschung als "Unsinn" ist jedenfalls unsachgemäss.

Vielleicht fühlte sich der User ja von dem derzeit etwas quietschroten
Rendering im Wald gestört.

Leider fällt der Urheber der Pfade auch nicht gerade durch einfallsreiche
CS-Beschreibungen oder Angabe von Quellen auf.

> Die microwave_links sind vermutlich Kollateralschaden.

Das bezweifle ich, da sie systematisch in allen 3 CS der Gruppe
(37796118 37799474 37806646 )
gelöscht wurden, im dritten ein ganzes Bündel.
Das spräche für einen unerfahrenen User, der etwas löscht was er
nicht kennt.


PS: Die Grenze natürlich auch


Ja, hier wurde nur ein Knoten aus einer gerade Linie gelöscht.

Sollte unsere Diskussion zu einem Revert führen, dann wäre das derzeit
konfliktfrei möglich wenn man alle 3 CS zugleich lädt.

tom



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

Re: [Talk-de] Radeln, rollern, schieben / Talk-de Nachrichtensammlung, Band 117, Eintrag 7

[Tom Pfeifer]

Bernhard Kuisle wrote on 2016/04/05 13:43:

Fußgängerzonen: Radfahren erlaubt - unerlaubt?
Die nächsten Zeilen sind unter Vorbehalt meines Gedächtnisses   .^)

1. Das Radfahren und auch das Radschieben sind wenn nicht ausdrücklich erlaubt 
in einer Fußgängerzone verboten.


https://dejure.org/gesetze/StVO/25.html
(2) Wer zu Fuß geht und Fahrzeuge oder sperrige Gegenstände mitführt, muss die 
Fahrbahn benutzen,
wenn auf dem Gehweg oder auf dem Seitenstreifen andere zu Fuß Gehende erheblich 
behindert würden.

Solange also keine erhebliche Behinderung vorliegt?


2. Das Rollern ist nach Gerichtsurteilen erlaubt. Rollern ist aber nur, wenn 
der Fuß auf dem Pedal ist, der beim Rollern auch auf dem Roller stehen würde.
D.h. für jemanden, der das Rad üblicherweise rechts schiebt, muss der rechte 
Fuß auf dem Pedal stehen. (Steht der linke Fuß drauf, ist er Radfahrer, da er 
jederzeit richtig aufsteigen könnte).


Vermutlich meinst du nicht rechtes oder linkes Bein (warum sollte ein 
Linksfüssler
nicht auf seinem rechten Pedal stehen?), sondern ob das Bein über den Rahmen
geschwungen ist oder nicht.

tom


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

Re: [Talk-de] bicycle=dismount von Routern ignoriert?

[Tom Pfeifer]

Carl von Einem wrote on 2016/04/04 16:00:

"§ 39 (3) Auch Zusatzzeichen sind Verkehrszeichen. Zusatzzeichen zeigen
... Aufschriften,..."

Eine Einschränkung, was in der Aufschrift stehen darf, finde ich dort
nicht.


Dann blättere bitte weiter bis § 41 Vorschriftzeichen, da findest du den Bezug 
auf die Anlage 2, [...]
Hier ist das konkrete Schild nicht aufgelistet.


Das hatte ich schon angesehen, auch dort steht nicht, dass es keine weiteren 
Aufschriften
geben kann.

Ausserdem mappe ich die Fakten wie ich sie vorfinde. In der StVO stehen auch 
keine
Blumenkübel. Wenn diese aber mitten auf der Strasse stehen, mappe ich eine
entsprechende barrier=* mit passenden access=* tag, Schild oder nicht Schild.


Zusatzzeichen [...] verkehrsrechtlich keinen Bestand und ist damit unwirksam,

> zumal der Verstoß gegen die Anordnung auch nirgends mit einem Verwarnungsgeld 
belegt ist.

Muss denn alles "verkehrsrechtlich wirksam" sein und mit Bußen belegt?
Darf man auch aufeinander Rücksicht nehmen, ohne das es durch rechtssichere
Schilder geregelt ist?


... keinen relevanten Tatbestant im Bußgeldkatalog, eine Ahndung ist
damit nicht möglich. (OLG Celle Az VRS 30,232)"


Man muss also kein Bußgeld zahlen, darf sich aber dennoch danach richten.
Die zitierten Urteile sind ja nur Reaktionen auf Einsprüche gegen Bescheide,
keine Verhaltensnormen.


ob die STVO Autofahrer bei irgendeiner Gelegenheit zum Schieben zwingt. Das 
wäre genauso absurd.


Die StVO nicht, aber vielleicht das Leben. Wenn die Karre im Dreck feststeckt,
bin ich für ein paar schiebende Zeitgenossen sehr dankbar, auch wenn sie nicht
durch Schilder dazu verpflichtet sind. :-)


[unter 6-9 Monaten] nicht als highway=construction erfasst werden sollten.


Sehe ich auch so, deswegen ist das immer noch ein highway=secondary mit
access-Tags. Conditional-Tags auch gerne, wenn sie denn vom Router auch 
ausgewertet
werden. Wobei dann die Evaluierungs-Reihenfolge wichtig wird, insbesondere
wenn für verschiedene Verkehrsarten verschiedene Bedingungen gelten.

tom

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

Re: [Talk-de] bicycle=dismount von Routern ignoriert?

[Tom Pfeifer]

Graphhopper kennt die Idee des Schiebens, es definiert für bikes 
"PushingSections"
für path, footway, pedestrian und steps, das passt zu meiner Beobachtung.
bicyle=yes/designated werden ausgewertet, =dismount aber nicht.

Ticket aufgemacht: https://github.com/graphhopper/graphhopper/issues/695

Carl von Einem wrote on 2016/04/04 11:05:

Das vom OP erwähnte Baustellen-Szenario würde ich aus zwei Gründen nicht mappen:
[...] "Fahrradfahrer absteigen" Zusatzschild ist nicht Teil der STVO


"§ 39 (3) Auch Zusatzzeichen sind Verkehrszeichen. Zusatzzeichen zeigen auf 
weißem
Grund mit schwarzem Rand schwarze Sinnbilder, Zeichnungen oder Aufschriften,..."

Eine Einschränkung, was in der Aufschrift stehen darf, finde ich dort nicht.


- zusätzlich werden Baustellen normalerweise nicht eingetragen [...];

> das müsste schon eine recht langwierige Baustelle [...] sein,

Ja, ein halbes Jahr Sperrung mit mehrkilometriger Umleitung ist für mich 
langwierig genug.

Die Formulierung "werden normalerweise" funktioniert in OSM nicht. Auch gibt
es verschiedene Vorschläge, eine befristete Sperrung zu taggen.

tom

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

Re: [Talk-de] bicycle=dismount von Routern ignoriert?

[Tom Pfeifer]

Bernhard Weiskopf wrote on 2016/04/03 22:19:

Bahnübergang für Fußgänger, ca. 20 m lang.
highway = footway mit bicycle = dismount:
GraphHopper, Mapzen und OsmAnd routen Fahrradfahrer über das Stück.
-> Alles in Ordnung.


Dann wird vielleicht highway=footway anders behandelt.

Mein Fall ist eine Baustelle auf highway=secondary,
wo nur noch Fussgänger und schiebende Radfahrer durchdürfen, daher
access=no, foot=yes, bicycle=dismount.

> Bei GraphHopper und Mapzen dauert das erfahrungsgemäß etwa 1-2 Tage und bei 
BRouter 1-2 Wochen.

Das ist berücksichtigt, insbesondere kennen die beiden Router ja die Sperrung 
schon
und schicken Autos und eben die Fahrräder weg, während Fussgänger durchgeroutet 
werden.

Brouter schickt mich noch durch, aber wohl erstmal wegen alter Daten 
('car-test' geht auch noch durch).

Liegt wohl wirklich am highway-tag, wenn ich mir zum Vergleiche den Spreetunnel 
anschaue, da werden
highway=footway+bicycle=dismount von GraphHopper und Mapzen genutzt, die beiden
highway=steps+bicycle=dismount aber nur von GraphHopper, nicht von Mapzen.

GraphHopper scheint ohnehin highway=footway ohne bicycle-tag zu nutzen, während 
Mapzen
dann einen weiten Bogen macht.

Frederik Ramm wrote on 2016/04/04 00:41:
> Klappe ---<
> so dass man als Fussgänger durchpasst, aber als Fahrradfahrer sein Rad

Ja, oder diese Teile:
https://wiki.openstreetmap.org/wiki/Tag:barrier%3Dfull-height_turnstile

Aber bei mir ist ja bicycle=dismount, das soll ja ausdrücken, solange ich 
absteige,
komme ich mit dem Rad auch durch.

tom

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