[Talk-de] Fragen an die Kandidaten (was: Vorstandswahlen der OSMF ...)

[Roland Olbricht via Talk-de]

Hallo zusammen,

außer der Kandidatur läuft auch sehr bald die Frist für Fragen an die
Kandidaten ab:
https://wiki.openstreetmap.org/wiki/Talk:Foundation/AGM20/Election_to_Board#Community_questions_to_OSMF_board_candidates.2C_upon_which_the_official_set_will_be_based
Damit da überhaupt was steht, habe ich die Fragen für 2019 kopiert und
angepasst. Ich werde mich im Übrigen zurückhalten, da ich nicht als
Kandidat die Fragen dominieren will.

Man kann und darf da auch Fragen auf Deutsch stellen, falls Englisch das
Hindernis ist. Bitte macht davon Gebrauch!

Wenn es also ernsthaftes Interesse an der Causa Facebook gibt, wäre es
gut, ein paar Fragen zu stellen, die die Lücke demonstrieren:

Attributierung: Was ist eine angemessene Form der Attributierung? Wie
soll die OSMF das gegenüber großen Unternehmen wie Facebook und Mapbox
durchsetzen?

Schäden durch KI: Die philippinische Community hat sich über zerstörte
Daten wie fälschlich verbundene Sackgassen durch "KI-Edits" beschwert?
Wie soll die OSMF solche und ähnliche Probleme durch organisiertes
Editieren einhegen?

Finanzierung der OSMF: Die OSMF hat sich durch ihre Angestellten auf ein
Budget verpflichtet, das viel höher als ihre Einnahmen aus
Mitgliedsbeiträgen ist. Soll die OSMF eine Abhängigkeit von großen
Sponsoren in Kauf nehmen?

Also: im Notfall (Deadline!) hilft es schon, die Fragen eins-zu-eins auf
die Seite
https://wiki.openstreetmap.org/wiki/Talk:Foundation/AGM20/Election_to_Board
zu kopieren. Noch mehr würde ich ich freuen, wenn jemand die Fragen
überdenkt, umformuliert, kürzt oder ergänzt.

Hinweis: wegen der Deadline auch ins Forum eingestellt.

Viele Grüße,

Roland

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

Re: [Talk-de] Vorstandswahlen der OSMF - Kandidatur bis 7.11. Ende des Tages

[Roland Olbricht via Talk-de]

Hallo,


Im Dezember ist wieder OSMF-Vorstandswahl. In ziemlich genau 52 Stunden
ist Ende der Bewerbungsfrist. Wenn ihr Interesse habt, als
Vorstandsmitglied zu dienen, könnt ihr Euch hier eintragen:

[..]> Ich selber bin ja nun schon eine Weile raus da, aber es ist meiner

Ansicht nach eine wichtige Arbeit. Die OSMF driftet ständig in Richtung
der "big business"-Leute, und auch dieses Jahr wird sich wieder Michal
Migurski zur Wahl stellen, der beim letzten Mal noch ganz deutlich in
seinem Wahlprogramm schrieb, dass er nicht als Privatmann, sondern als
Vertreter von Facebook in den Vorstand will - für mich eine sehr
schwierige Vorstellung.


Auf die Liste habe ich mich jetzt eingetragen. Wenn noch jemand Lust
hat, trage ich mich gerne wieder aus. Es bleiben bei mir ohnehin schon
mehr OSM-Themen liegen als mir lieb ist.

Ich denke aber, dass es schwierig wird, gezielt einen unerwünschten
Kandidaten draußen zu halten: das verwendete Wahlsystem STV hat ja
gerade als Zweck, die Chancen von Nischen-Bewerbern zu verbessern und
taktische Züge zu erschweren.

Eine Bitte an alle diejenigen, die mich wählen wollen: Mit Tobias'
Arbeit bin ich sehr zufrieden und möchte ihn auf keinen Fall verdrängen.
Setzt ihn also daher bitte VOR mich auf den Wahlzettel.

Zur Taktik: wenn ich Michal verdrängen soll, muss ich darauf abzielen,
bei möglichst vielen Wählern vor ihm auf dem Wahlzettel zu stehen, die
absolute Position ist weitgehend egal. Ich werde daher mit einer eher
business-freundlichen Position auftreten, die ich aber nicht in der OSMF
fortzusetzen beabsichtige. Generell ist der Zweck der Overpass API ja,
dass mehr Leute zu Tagging-Fragen auf Augenhöhe mitreden können, und die
Share-Alike-Lizenz ist wohlabgewogen gewählt.

Viele Grüße,

Roland

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

Re: [Talk-de] Evangelische Kirchen in Deutschland

[Roland Olbricht via Talk-de]

Hallo zusammen,

die Idee für die Wochenaufgabe verdient auf jeden Fall Unterstützung.

Jenseits des denomination-Tags lohnt es sich bei allen Gemeinden, auch
die URL der Gemeinde, die das Gebäude nutzt, einzutragen. Neben der
Service-Funktion, um tatsächliche Gottesdienst- und Öffnungszeiten zu
finden, ist das auch in der Zukunft der beste Indikator, ob die Kirche
noch aktuell ist.


so einfach ist das leider nicht. Die deutschen evangelischen Kirchen
sind je nach Region entweder lutherisch, reformiert oder uniert.


Um den längeren, sehr interessanten Unterschied
https://de.wikipedia.org/wiki/Reformierte_Kirchen
https://de.wikipedia.org/wiki/Union_Evangelischer_Kirchen
mal abzukürzen: es gibt größere gemischte, aber auch fast ausschließlich
lutherische oder reformierte Gebiete in Deutschland

Als On-the-ground:
Wenn es einen stilisierten fast-nackten Mann über dem Altar gibt, dann
ist es sicher lutherisch, die reformierten Gemeinden orientieren sich am
immer Wort und haben abstrakte Kreuze.
Mitunter sind lutherische Nebenstellen aber so schlicht gestaltet, dass
die Umkehrung nicht gilt.

Es ist im Zweifel keine Schande, denomination=protestant zu notieren,
nur halt sehr unpräzise. denomination=lutherian ist dagegen häufig
genauso falsch wie denomination=evangelical

Viele Grüße,

Roland

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

Re: [OSM-talk] Referential integrity of https://planet.openstreetmap.org/replication/minute//004/146/694.osc.gz

[Roland Olbricht via talk]

Hi all,


There is a new release of the Overpass API
https://dev.overpass-api.de/releases/osm-3s_v0.7.56.6.tar.gz
that adheres to these rules.


Unfortunately, getting network communication right is hard. In that
version, there is a race condition. For that reason, there is another
new release 0.7.56.7.

You can run that release and keep the database, in particular if an
update based on 0.7.56.4 or 0.7.56.6 has ended with

gzip: stdin: unexpected end of file
Reading XML file ...Parse error at line 23105:
unclosed token

This means that apply_osc_to_db.sh has tried to use an XML file before
fetch_osc.sh has completed to download it. It is harmless, in this case
the automatic emergency stop has applied early enough. Please do the
following (with EXEC_BASE_DIR, DB_DIR and DIFF_DIR appropriately replaced):

# Install new bash scripts over the exisiting broken ones
$ pushd "$EXEC_BASE_DIR"
$ cp ~/osm-3s_v0.7.56.7/bin/fetch_osc.sh bin/
$ cp ~/osm-3s_v0.7.56.7/bin/apply_osc_to_db.sh bin/

# Kill the frozen existing processes and remove the lock file
$ ps -ef | grep apply
roland   19676 1  0 Aug13 ?00:00:08 bash
bin/apply_osc_to_db.sh /opt/osm3s/diff/ auto --meta=attic

$ ps -ef | grep 19676
roland   19676 1  0 Aug13 ?00:00:08 bash
bin/apply_osc_to_db.sh /opt/osm3s/diff/ auto --meta=attic
roland   20652  4841  0 04:09 pts/000:00:00 grep --color=auto 19676
roland   21629 19676  0 Aug13 ?00:00:00 ./update_from_dir
--osc-dir=/tmp/osm-3s_update_VUkjcE --version=2020-08-13T20\:33\:03Z
--keep-attic --flush-size=0

$ kill 19676 21629
$ rm /ssd/osm3s/db/osm_base_shadow.lock

$ ps -ef | grep fetch
roland   23675 1  0 Aug13 ?00:00:06 bash bin/fetch_osc.sh
4146694 https://planet.openstreetmap.org/replication/minute/
/opt/osm3s/diff/
roland   27830  4841  0 04:11 pts/000:00:00 grep --color=auto fetch

$ kill 23675

# Restart the diff processes
$ nohup bin/fetch_osc.sh $(cat /ssd/osm3s/db/replicate_id)
'https://planet.openstreetmap.org/replication/minute/' "$DIFF_DIR"
>>fetch_osc.out &
$ cat "$DB_DIR/replicate_id"
4150150
# Must exist and contain a meaningful diff id, this is a new lock file

$ nohup bin/apply_osc_to_db.sh /opt/osm3s/diff/ auto --meta=attic
>>apply_osc_to_db.out &
$ sleep 30
$ tail apply_osc_to_db.out
/opt/osm3s/bin /opt/osm3s
Reading XML file ...
# Should show some messages after the "read unclosed token" error
# The first ones are the output of pushd to $DB_DIR/bin and the progress
line "Reading XML file ..." and so on

I'm sorry for the inconvenience and hope that this has fixed all race
conditions. Not yet adapted is "fetch_osc_and_apply.sh". If someone uses
this then please mail me. I will then watch with you whether an improved
version of that script is stable.

Best regards,
Roland

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

Re: [OSM-talk] Referential integrity of https://planet.openstreetmap.org/replication/minute//004/146/694.osc.gz

[Roland Olbricht via talk]

Hi all,


in the minute diff, in file
https://planet.openstreetmap.org/replication/minute//004/146/694.osc.gz
the way 40657824 uses node 7804408284, but that node is contained
neither in 694.osc.gz nor in any earlier minute diff.


It's in 693 as far as I can see?

Tom


I would like to thank mmd for the investigation and TomH for clarifying
the correct order of diff downloads, see
https://wiki.openstreetmap.org/wiki/Planet.osm/diffs#Fetching_diff_files

There is a new release of the Overpass API
https://dev.overpass-api.de/releases/osm-3s_v0.7.56.6.tar.gz
that adheres to these rules.

Best regards,
Roland

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

[OSM-talk] Referential integrity of https://planet.openstreetmap.org/replication/minute//004/146/694.osc.gz

[Roland Olbricht via talk]

Dear all,

in the minute diff, in file
https://planet.openstreetmap.org/replication/minute//004/146/694.osc.gz
the way 40657824 uses node 7804408284, but that node is contained
neither in 694.osc.gz nor in any earlier minute diff.

In addition, it looks like there are large batches of nodes missing.
From the create block:
   
  
  
  
  



There are multiple other referential integrity errors as well.

This has caused an emergency stop for the Overpass API updates, because
otherwise it would produce broken data. I'm sorry for that.

Could someone from the sysadmin team please have a look at the file?

Best regards,

Roland


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

Re: [OSM-talk] Proposal for Software Dispute Resolution Panel

[Roland Olbricht]

Hello,

first of all I'm glad to read that the board addresses the sudden
funding hole for iD, and does in addition care about the critique around iD.

I would like to self-nominate for the software dispute resolution panel.

For my understanding of the task please (re-)read
https://lists.openstreetmap.org/pipermail/osmf-talk/2020-June/006909.html
tl;dr: There is no silver bullet, hence no team of experts is going to
find one. Conflict resolution is painful work for all involved, but it
also likely to yield insight and an improved software. I see a panel's
member's job in encouraging the involved people to keep walking through
the resolution process.

I also promise resp. reserve the right to share or paraphrase (for the
purpse of removing personal issues) all communications regarding the
nomination process. There have been concerns about whether the
nomination process is balanced and being open is the best way to address
them. On a personal note: I have no doubts it is, and the artifacts we
currenty encounter are consistent with a board intensely keeping many
trains in their rails in parallel.

Regarding potential CoI:
- I develop the Overpass API but it is intentionally tag agnostic.
- I do not plan to put the Overpass API under the panel regime.
Thus, I do not expect any CoI from my contributions as developer to
OpenStreetMap.

Best regards,
Roland

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

Re: [OSM-talk] OSM nicknames are Unicode characters? (not Ascii?)

[Roland Olbricht]

See 
https://www.openstreetmap.org/user/%F0%9D%96%92%F0%9D%96%86%F0%9D%96%98%F0%9D%96%99%F0%9D%96%97%F0%9D%96%94
URL-Percent-Encoding works fine, so does the involved XML. It is
solely a problem of UX software.

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

Re: [Talk-de] Regionalbahn-Relationen: was in network einzutragen?

[Roland Olbricht]

Hallo Michael,


Mir ist noch etwas eingefallen, was bei der Aufgabenträger-Bedeutung
problematisch wäre


Ich denke mal, dass die Idee hinter dem "network=" urpsrünglich mal war,
dass derjenige drinsteht, der die Liniennummer vergibt. Dann ist die
Kombination aus network= und ref= für jede Linie eindeutig.

Es ist eine recht häufige und naheliegende Forderung, dass man mit einem
einfachen Filterkriterium genau die gesuchte Linie finden kann, und da
hilft die Eindeutigkeit.

Der Rest ist jetzt das übliche Missverständnis-Potential. Bei den alten
Verkehrsverbünden (z.B. MVV, VRR, VRS) sind die Liniennummern
verbundweit koordiniert. Daher dürfte (für vor allem Busverkehr) die
Formulierung "network= ist der Verkehrsverbund" stammen.

Bei neueren Verkehrsverbünden ist das nicht mehr der Fall. Wer aus einem
solchen kommt, wird aus der Vorgabe "network= ist Verkehrsverbund" nicht
zurückschließen, dass die Eindeutigkeit das wesentliche Merkmal ist, und
sich seine Eindeutigkeit auf anderem Wege basteln, z.B. unter Mitnutzung
des "operator=" (mit eigenen Schwierigkeiten) oder Ähnliches.

Jedenfalls kann man auch aus Semikolon-Listen in "network=" (plus
"ref=") noch einen einfachen Filter bauen, der genau die gewünschte
Linie findet. Von daher kann man das machen, sollte dann aber im
Zweifelsfall mehr eintragen, damit der Filter nicht ins Leere greift.

Eine ungelöste Aufgabe ist dann, was man mit den Verkehrsverbünden
macht, in denen Liniennummern mehrfach vorkommen.

Von der Berücksichtigung von Tarifinformationen würde ich dagegen sehr
dringend abraten: es gibt endlos viele Sonder- und Kulanzregeln, oder
nur teilweise gültige Sortimente. Es kann durchaus passieren, dass auf
einem bestimmten Abschnitt nur Zeitkarten eines Verbundes anerkannt
werden. Sonst müsste man z.B. auch anfangen, Regelungen wie das
Bahncard-Cityticket im "network="-Tag einzutragen.

Viele Grüße,

Roland

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

[OSM-talk] Overpass API version 0.7.56

[Roland Olbricht]

Dear all,

I'm back with providing updates. After more than a year I'm proud to
present a new release. This release provides some smaller new features.

It is possible to use _angle()_ to filter ways by the angles of their
inner vertices. This way, you can find e.g. non-rectangular buildings or
unintended whiskers.
https://dev.overpass-api.de/blog/total_0_7_56.html#angle

A recurse can now be restricted by the relative position of the entry in
the object. I.e. you can obtain only the first or only the last node of
a way.
https://dev.overpass-api.de/blog/total_0_7_56.html#memberpos

The idea of _nwr_ has been extended both to variants _nw_, _wr_, and
_nr_. And it is now possible with the count evaluator as well.
https://dev.overpass-api.de/blog/total_0_7_56.html#type_shortcuts

For the users of own instances, queries can now be passed by the command
line parameter _--request=_ as well.

Two larger features have been hold back because they break the database
layout, and I do not want to do that too often: support for large
objects (which are necessary to have Antarctica as an area) and a
reoriganization of access to attribution data (changeset ids, user ids,
user names). I intend to bundle them with the necessary changes to use
ways and relations directly as areas,
but that is not implemented yet.

Best regards,

Roland

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

Re: [OSM-talk] Proposed new status for tags in the wiki: "import" for undiscussed tags that were only used by an import

[Roland Olbricht]

I would like to add a new status to
https://wiki.openstreetmap.org/wiki/Approval_status and to Tag and Key
pages in the wiki

The value "import" would be used for tags that were used in a large
import, but are no longer commonly being added.


The misunderstanding about "object:street" has already shown that things
are probably not that easy. The tag is in widespread use, but just not
on the entire planet.

In other words, that status "import" would conflate at least three very
different things:

"local": tags that are in use by a local community. There are many more
subtle things that are important locally but do not make sense on a
global scale. The "object:street" is an example of this, or
"addr:conscriptionnumber" mostly in Austria. "crossing_ref" is an
example for an UK specific tag, GNIS are local to the US and so on.

"external": There are quite a lot of references to an external databases
(e.g. "ref:bag", "osak:identifier", "wikidata", IFOPT and NaPTAN). They
may or may not be global. In any case, they are meaningless unless you
have access to the source database as well, as opposed to "local" which
are verifiable on the ground.

"stale": Tags that came with an import, are not, and can not be used by
general mappers, and are not expected to be updated. "tiger:cfcc" is
currently the most numerous. The low number of values of "tiger:cfcc"
makes it unlikely that it is carrying any meaning.

Another final question is whether it makes sense to refine the system at
all. Much of the information of the tagging classes is available via
taginfo, and some more can be automatically computed from the database,
although it is it done today. Having this is as explicit information
instead is the either redundant (if in line with actual database
content) or misleading (if in contradiction to the actual database content).

Best regards,

Roland

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

Re: [Diversity-talk] [Osmf-talk] First Meeting of Diversity and Inclusion Special Committee

[Roland Olbricht via Diversity-talk]

Hi all,


4) Some aspects of the diversity discussion foreground northern/western
participation channels by (for example) wondering why other communities
aren't participating in Talk@, SOTM, or other locations. I’m interested
in trying to flip this question to ask why core board and community
participants aren't showing up in forums like geographic Telegram groups
or other locations called out at https://openstreetmap.community ?


I am on the German Telegram group to help keeping the community
connected. Beside idealism it is quite repelling:

- You need an invitation to get in at all. By contrast, one can join the
mailing list in self-service.

- Some new users have been greeted with questions like "Justify why you
use OpenStreetMap!" (original: "Warum nutzt Du OSM?").
- citations like "Are the people too stupid to code?" (original: "Sind
die Leute zu blöd zum Programmieren?")

All-in-all, the group actually has a sometimes derogative tone. This is
completely acceptable within German commnication styles, because
messages are intended to be quick and shallow. It is more about
socalizing than sorting out intricate problems. Socalizing works much
better for me on local OSM meet-ups.

But I can contribute to OSM conversations mostly in batches - the only
reliably available time window I have to contribute is the one-hour
train ride from and to work. Office time is unfortunately not OSM time
for me. As I take my responsibilities on housework seriously, time at
home may or may not leave spare time for OSM.

Thus, opening Telegram means that one has to sift through a large pile
of messages, reading 100% of the actual text, and no auxiliary tools to
sort messages into threads and skip some or most of them. When I have
priorized which messages may need an reply from me, half of the train
ride may already have passed.
By contrast, mailing lists do allow to easily skip over less interesting
threads and to focus on those where my reply makes a difference.

All in all, I do accept that there is a place for a communication
channel that allows socalizing beyond local meet-ups. I accept that I
have a certain duty to listen there for messages. I do not expect that I
am ever drawing an satisfaction from that. I'm more the guy behind the
screen in this cartoon:
https://heeris.id.au/2013/this-is-why-you-shouldnt-interrupt-a-programmer/
On the other hand, I expect from people that if
- a problem requires more than 100 words to pinpoint the subtle but
important details
- it is general enough to be publicly archived
then put the problem on the mailing list to make it easier for fellow
OSMers to answer in the necessary depth.

Probably nobody has intentions to shut down on extra channels like
Telegram. The problem comes from the mis-representation that those
channels were preferred channels, in particular for deep and important
topics.

Best regards,

Roland

___
Diversity-talk mailing list
Code of Conduct: 
https://wiki.openstreetmap.org/wiki/Diversity/MailingList/CodeOfConduct
Contact the mods (private): diversity-talk-ow...@openstreetmap.org

[OSM-talk] User manual for the Overpass API

[Roland Olbricht]

Hello,

for the Overpass API, a user manual is now accessible at
https://dev.overpass-api.de/overpass-doc/en/

Key features:
- It is a guided tour (and neither a full reference nor an example
library, which both are useful but separate resources)
- Focus on long term stable functionality
- Intended to be easily translated, 2 translations already available

The user manual aims to fulfill the desire for a more comprehensive
documentation. I hope that more mappers get empowered to user features
beyond simple key=value and bounding boxes. For this reason, alternativa
language versions in German and French are offered as well.

Although the user manual is still in the process of being written,
the essential chapters "Preface", "Spatial Data Selection", and "Find
Objects" are populated. The other chapters and the missing section in
these chapters will follow in the coming months.

For the languages:

More translations are highly welcome, and localizations of the examples
as well. You can either do a pull request on
https://github.com/drolbr/overpass-doc
or send them by other means. There has been a tool integrated to track
updates paragraph by paragraph
https://github.com/drolbr/overpass-doc/blob/master/helper_scripts/blame_recursively.sh
such that keeping the translation up to date should much easier than in
the wiki.

German, English, and French are simply the languages that I'm able to
communicate in and by no other means special.

Relating to other existing documentation:

The manual collects long-term valid information and is not even intended
to store short-term information. Short term information will continue to
go into the wiki.

A much larger legacy is help.openstreetmap.org . Others and me have
provided beside helpful information a lot of workarounds that are now
much too complicated. Even worse, there are then-truthful answer about
absent features that have been implemented in the meanstime. That source
lacks a mechanism to hide or delete outdated answers, and is in this
regard damaged beyond repair.

An example library would still be very helpful. There are several
examples on
https://wiki.openstreetmap.org/wiki/Overpass_API/Overpass_API_by_Example
https://wiki.openstreetmap.org/wiki/Overpass_API/Advanced_examples
and in their translations (not synchronized), but much more probably
exist elsewhere and not easy to find.

Some older documentation pages on https://overpass-api.de/ will be
decomissioned once I have found the time to rewrite updated versions of
them for the manual.

Viele Grüße,

Roland

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

Re: [Talk-GB] Reference numbers for UK admin areas?

[Roland Olbricht]

Hi all,

I'm at the moment writing a documentation for the Overpass API.


The challenge was to get Overpass to return grit bins in /this /Sutton,
and not in all places called Sutton.


Coincidentially, I just have translated a section about that type of
question:
https://dev.overpass-api.de/overpass-doc/en/full_data/area.html#per_tag
I'm grateful for the oppurtunity to place this appetizer.

Please feel free to ask any questions. The audience of this
documentation are average mappers, thus all feedback can help to expand
or clarify sections that are incomprehensible.

As this is work in progress, I'm sorry that not yet all cross references
within the documentation work, usually because the referenced content is
not yet translated.

I'm confident to have it complete before the end of the year. I will
make an annoucement when the documentation is referentially complete and
again when it is content complete.

Best regards,

Roland

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

Re: [Talk-de] Kreuz Werl - seltsame Spurnutzung

[Roland Olbricht]

Hallo Michael,


Was für eine Geschwindigkeit sollte vom routing bei signals angenommen
werden?


Kurzfassung: Ich würde mir
120 km/h für maxspeed=signals  und
 80 km/h für highway=motorway_link
wünschen.

Zu maxspeed=signals kenne ich viele der Anlage in NRW
https://overpass-turbo.eu/s/N9k

Auf dem Kölner Ring und der A46 bin ich regelmäßig und auch zu allen
Tageszeiten unterwegs. Dort sind tatsächlich niemals mehr als 120 km/h
ausgewiesen. Auf der Anlage auf der A1 bei Dortmund gibt es vereinzelt
auch die Richtgeschwindigkeit.

Es gibt aber auch prinzipielle Überlegungen: in Deutschland kann wegen
der Richtgeschwindigkeit vernünftigerweise keine Autobahn mit mehr als
130 km/h berechnet werden. Die Definition der Richtgeschwindigkeit
besagt ja, dass der Betreiber der Autobahn auch bei günstigen Wetter-
und Verkehrsverhältnissen eine höhere Geschwindigkeit für gefährlich
hält. Insofern sollte ein guter Router auch niemanden zu gefährlichem
Verhalten verleiten. Die 120 km/h sind also selbst bei Anzeige von
Richtgeschwindigkeit nur geringfügig zu langsam bemessen.

Umgekehrt wird eine niedrigere Geschwindigkeit als 120 km/h
hauptsächlich dann angezeigt, wenn Staus oder schlechten Verkehrs- oder
Wetterverhältnissen vorgebeugt werden soll. Das ist aber außerhalb des
Anspruchs eines Routers mit statischen Daten. Ein Stau-Modell haben wir
auch nicht für Autobahnen mit fixem Limit. D.h. wer in der
Hautverkehrszeit Routen berechnet, wird für realistische Zeiten ohnehin
einen Router mit Echtzeitdaten oder sogar Prognosemodell bemühen wollen.
Von daher fällt auch die Abweichung nach unten nicht groß ins Gewicht.

Zu den Rampen, also highway=motorway_link: Das Konzept der
Selbstverantwortung ist überraschend prominent in der deutschen
Verkehrsordnung. Geschwindigkeitbegrenzungen dienen vorwiegend dazu,
eine Fremdgefährdung auszuschließen. Ich kenne durchaus enge
Linkskurven, vor denen das Geschwindigkeitslimit aufgehoben wird, obwohl
man schon das praktisch nicht fahren kann. Linkskurve heißt: man fährt
nur sein eigenes Fahrzeug in den Abgrund. Das formale
Geschwindigkeitslimit ist also nicht automatisch die vernüftigerweise
oder selbst realistischerweise fahrbare Geschwindigkeit.

Verbindungsrampen werden oft mit Entwurfsgeschwindigkeiten von 40 km/h
bis 60 km/h konzipiert. Schaut man sich die Kurvenradien der Kleeblätter
am Autobahnkreuz in Werl an, so sind dort auch eher 40 km/h oder weniger
konzipiert worden. Ein explizites Schild gibt es an solchen Kurven nur
vereinzelt (speziell Werl kenne ich nicht, bei anderen Autobahnkreuzen
gibt es beide Fälle), aber OSRM hat meines Wissens auch keinen
Präprozessor, der Kurvenradien auf Geschwindigkeitsgrenzen umrechnet.
Damit bleibt außer dem Tag highway=motorway_link aus Sicht der Routers
kein besserer Indikator.

Entsprechendes gilt für die Verflechtungsstreifen. Auch dort ist zwar
kein Limit ausgewiesen, aber die Gefahr langsam auffahrender Fahrzeuge
und das nötige Bremsmanöver zum Abbiegen bedeuten, dass auch dort
effektiv Geschwindigkeiten von weniger als 80 km/h gefahren werden können.

Von daher würde ich für einen Router nach aktuellem Stand der Technik
(Auswertung von Tags im Kantenmodell, keine Kurvenradien, keine
Erkennung von Verflechtungsstreifen, kein probabilistisches Staumodell)
die beiden Limits empfehlen. In über 95% der Fälle wird man damit den
real sinnvollsten Weg mit einer bis auf Stau nahezu korrekten Zeit
bestimmen können.

Viele Grüße,

Roland

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

Re: [Talk-de] Fragen, Anregung eines Neulings

[Roland Olbricht]

Sehr geehrter Herr Mehl,


https://routing.openstreetmap.de/?z=15=50.738180%2C8.291759=49.908459%2C8.647996=51.956580%2C7.632351=de=0=0

erhalte ich zwei unverständliche Umleitungen:

   - die A5 nicht bis zum Gambacher Kreuz, sondern vorher Abfahrt
     um Butzbach, Langengöns
   - um Herborn herum auf der B277,


erst einmal herzlich willkommen und danke für die Rückmeldung. Das ist
durchaus schon konkret genug, um den konkreten Mangel zu finden.

Das schöne bei Open-Source ist, dass jeder der Ursache noch weiter
nachgehen kann. Zum Nachfolgenden möchte ich Sie gerne ermuntern, aber
nicht verpflichten; für die erfahrenen Leser ist aber aber sicherlich
gut zu wissen:

In diesem Fall gibt es unten links auf der Routing-Ansicht, drittes
Symbol (Lupe vor Quadrat) eine sogenannte Debug-Ansicht:
https://routing.openstreetmap.de/debug/car.html#14/50.4915/8.6899
Dort bleibt die Fahrbahn Richtung Dortmund grau. D.h. aus Sicht der
Ruting-Software ist diese Fahrbahn nicht befahrbar.

Ab diesem Punkt könnte man den Macher der Routing-Software anschreiben,
https://routing.openstreetmap.de/about.html
liefert fossgis-routing-ser...@openstreetmap.de
als Ansprechpartner.

Oder selber herausfinden, warum die Fahrbahn nicht verwendet wird:
https://overpass-turbo.eu/s/MNy
liefert die fraglichen Elemente sowie die Elemente kurz davor und
dahinter, zum Anklicken mit Sicht auf die Tags.
Bei den Tags unterscheiden sich die routbaren Elemente von den nicht
routbaren Elementen am Ehesten durch das Tag "construction=yes".

Wie sich herausstellt, wenn man auf
https://routing.openstreetmap.de/about.html
nach den Routing-Regeln
https://github.com/fossgis-routing-server/cbf-routing-profiles/blob/master/car.lua
schaut, dann findet man, dass

avoid = Set {
[...]
  'construction',
  'proposed'
},

d.h. es wird in der Tat die Route von routing.openstreetmap.de nicht
genutzt, weil "construction=yes" gesetzt ist. Hier wäre jetzt die
Einschätzung gefragt, ob das Tag "construction=yes" gerechfertigt ist.
Aus der Erfahrung und Beschreibung auf
https://wiki.openstreetmap.org/wiki/DE:Key:construction
liest man, dass das Tag nicht verwendet werden sollte (sondern
"highway=construction" + "construction=motorway", wenn und nur wenn die
Fahrbahn unbefahrbar ist).

An dieser Stelle ließe sich nun entweder das Tag entfernen oder
sinnvollererweise per Changeset-Diskussion der Mapper kontaktieren, was
das Tag "construction=yes" eigentlich hätte sein sollen. Ich habe das in
https://www.openstreetmap.org/changeset/74156647
jetzt getan.

Wie gesagt, die komplette Recherche würde ich zwar nicht erwarten, aber
es ist ein guter Fall vorzuführen, warum durch Open Source man schnell
den richtigen Ansprechpartner mit dem richtigen Kontext finden kann.

Viele Grüße,

Roland Olbricht

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

[OSM-talk] Wording (was: Re: From the SotM: tagging session)

[Roland Olbricht]

Hello,

I'm happy to help out understanding the report of the discussion session.


It has been a talking point that the wiki should be purely descriptive.
There is no objection that people sort out tagging questions in the
wiki, but the mixture of purely descriptive and as normative intended
pages would cause confusion.



By "normative" do you mean prescriptive?


I do mean "normative".

I have considered to use the pair of notions "descriptive -
prescriptive", but there is potential to confuse the terms on
superficial reading. I also understand "prescriptive" to have a
derogative connotation, and I do not intend to express that.

For the pair of notions "positive - normative" the meaning (according to
e.g. Wikipedia
https://en.wikipedia.org/wiki/Normative
) is:

  normative - How something should be
  positive - How something actually is

That is exactly the meaning as settled on in the discussion: the purpose
of the wiki documentation was to tell how the tagging is used. However,
given that "positive" is a very general term, I have used the pair
"descriptive - normative".

Best regards,

Roland

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

[OSM-talk] From the SotM: tagging session

[Roland Olbricht]

Hello everybody,

I have promised to report results from the tagging session at the SotM.
I'm sorry for being late. The good news are that there is a relatively
actionable item that has found general acclaim.

We would like to have a secondary tag documentation with the properties:

- It is stable and permanent.

- It is strictly descriptive. In particular, this means that it must be
able to cover multiple tagging approaches even if they contradict each
other.

It has been conjectured that having a personal responable per subject or
even per individual page could help with quality. Everybody has agreed
that this approach comes in addition to the existing wiki and not as a
replacement.

A lot of other tpoics have been touched.

It has been a talking point that the wiki should be purely descriptive.
There is no objection that people sort out tagging questions in the
wiki, but the mixture of purely descriptive and as normative intended
pages would cause confusion.

A tagging working group to write the Map Features pages has been
discussed. But the current state of existing working groups does rather
not suggest that is going to be self-sustaining.

I'm in particular grateful that developers from the major editors have
participated in the discussion. The people in the room were in general
happy with the editor's handling of tags as of now.

The general mood of the room was calm and constructive.

Best regards,

Roland

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

Re: [OSM-talk] Tagging Governance

[Roland Olbricht]

Hello everybody,

first of all, I am grateful that the responses have all been calm and
well-thought. I will make room in the session to document the results of
this discussion.


Changing to a github-like system of version management


I thought of Git, not Github.

This is an important distinction: Git is as decentralized as possible -
whenever one works with a repo one gets the full data and history of the
project to the local disk drive.

The point about Git is that it groups related changes over multiple
files in a single structure called commit. This is opposed to the
Mediawiki approach which keeps changes to files in strict isolation.
Thus the question is: are contradictions between pages a problem? If yes
then a holisitic toolset may do better, if not then the holistic tool
has no advantage in this regard.

Opposed to this, Github is a profit oriented company essentially
offering web storage in a fancy way. Relying on Github or similar for
crucial ressources of OpenStreetMap is a no-no: Even if Github's geniune
business interests do not conflict with our needs, politics come into
play. Github had been targeted by 3rd country internet censoring, US
export restrictions, frivolous and substantial takedown requests, and
probably more. For the same reason I consider the silent integration of
Wikimedia resources into our Wiki for problematic: the last outage is
only a couple of days away, and has been neither to blame on Wikimedia
nor under their control. Yet it affected the usability of our Wiki.

Best regards,

Roland

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

[OSM-talk] Tagging Governance

[Roland Olbricht]

Hi all,

I have got into the duty to talk about tagging governance on the SotM
and I would like to develop that opportunity towards something that is
rather helpful in the long term.
To ensure that I am on the right track and not unintentionally after a
personal agenda I would like to ask you to comment on the findings so
far listed below.

To encourage a widespread discussion, I have spread this message on
German and French lists as well (these two because I understand the
languages) and will do so in addition on the tagging list. Feel free to
spread this message further as long as you remember to channel back all
feedback.


Imperfect Flow of Information

Although many parts of the OpenStreetMap project are well translated,
the tagging documentation has substantial deficiencies. Over a random
sample of 10 tags the number of declared languages varies between 2 and
18, but only few are complete and up to date (sample: 2 of 10 for
German, 3 of 10 for French).

Another kind of imperfect information flow is that tag definitions can
be changed on the wiki page long after the tag is in widespread use.

The converse case that a tag is introduced without any documentation is
also happening. While this happens by ordinary users usually slow enough
to make sense of the added data, an import or organized edit might be
able to substantially skew the de facto meaning of a tag, regardless
whether it is in widespread use, documented, both, or none.


More Structure needed

The translation issues have been conflated with a different problem:
Different features may look very different between regions. E.g.
highway=primary and highway=unclassfied versus highway=track
need different sets of examples in Germany and the urban US on the one
hand and Iceland or rural Africa on the other. It is easy to mix this
with the translation into the predominant language in the area,
but the tagging challenges in Belgium, Canada, and Niger are
substantially different, although all three countries happen to have
French as official language. Conversely, there is no sane reason to
change tagging rules every block of houses in Brussels.

Additionally, people often have different search terms than the British
English tag names or their translations, and the wiki search engine is
infamous for its bad performance. Having explicit keywords to direct the
attention of a mapper to the list of possibly fitting tags might help.

A substantial problem source of the concept of proposals is
that it interacts with lots of tags in a nontrivial way and is
practically never properly applied to all affected tag definitions.
A proposal currently is an extra page although it should have much more
an impact like a Git commit, grouping changes across various tag
definition pages in a single changeset.


Legitimacy and Governance

What legitimation has a process if only a handful of people have that
have the time to write mails on a mailing list and to write wiki pages
are involved? In particular, if the proposals end up as being full of
contradictions or vague terms and leave necessary answers undefined.
Yet these still are the people that have shown the necessary long-term
endurance to assure maintenance and that do the work. Thus every change
to replace processes with better processes must be geared towards
broadening not narrowing the base of long-term maintainers.

Conversely, I fully understand mappers that are wary of sudden changes
in the rendering or the access to tags in edting software. A lot of
people whould probably appreciate to better understand what happens on
the way from a tag discussion to a final change in the renderer or
editing software. These processes are not secret, but often
under-documented.

Again, the various discussion channels and the lacking information flow
between them contribute to the bad mood. Even worse, the ratio between
people and channels means that evil or just plainly incompetent people
could easily take over some channels and contribute substantially to the
confusion. Good ideas how to redirect people and close down some of the
channels (e.g. wiki discussion pages) might be worth pursuing. On top of
that the wiki history is so much less helpful than what developers are
nowadays used to from version control systems that borrowing methaphors
and paradigms from there to the tag documentation is worth consideration.

This hopefully helps to foster that the authors of the documentation and
the mappers using a tag actually agree on its meaning.


Best regards,

Roland

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

[Talk-de] Spielregeln fürs Tagging

[Roland Olbricht]

Hallo zusammen,

bei der SotM werde ich eine Stunde zum Thema Tagging moderieren
und will die Gelegheit nutzen, etwas möglichst langfristig Hilfreiches
zu schaffen. Damit ich dabei nicht meine persönlichen Wünsche über die
tatsächlichen Bedürfnisse stelle, würde ich mir Rückmeldung wünschen,
inwiefern die nachfolgend gelisteten Probleme auch die relevanten sind.

Die Mail darf gerne weitergereicht werden; ich strebe eine breite
Diskussion im Vorfeld an.


Mängel im Informationsfluss

Zwar sind viele Teile von OpenStreetMap gut übersetzt,
aber die Tagging-Dokumentation hat spürbare Mängel. Bei einer Stichprobe
von 10 Tags sind zwar per Tag zwischen 2 und 18 Sprachen gelistet
worden, aber nur wenige der Übersetzungen sind vollständig und aktuell
(in der Stichprobe 2 für Deutsch, 3 für Französisch).

Ein anderes Defizit ist, dass Tag-Dokumentationen auf den Wiki-Seiten
auch dann erheblich geändert werden können, wenn das Tag längst breit in
Gebrauch ist.

Es kommt zudem ebenso vor, dass ein Tag ohne jegliche Dokumentation
eingeführt wird. Wenn dies durch normale Mapper passiert, ist dies
üblicherweise langsam genug um das Tag deuten zu können; so können
Imports oder Organisiertes Editieren die De-Facto-Bedeutung eines Tags
substantiell verschieben, unabhängig davon ob es verbreitet,
dokumentiert oder beides ist.


Bedarf nach mehr Struktur

Die Tag-Übersetzungen mischen sich mit einem anderen Problem:
verschiedene Features können sehr unteschiedlich in verschiedenen
Regionen aussehen. Z.B. sehen ein highway=primary und
highway=unclassified gegenüber highway=track in Deutschland deutlich
anders aus als in Island oder dem ländlichen Afrika. Es passiert
schnell, dass lokale Unterschiede nur in die Übersetzung der jeweils
dominanten Sprache eingehen, obwohl z.B. die Tagging-Anforderungen in
den französischsprachigen Ländern Belgien, Kanada und Niger spürbar
verschieden sind. Umgekehrt gibt es keinen sinnvollen Grund, die
Tagging-Regeln in Brüssel pro Häuserblock zu ändern.

Darüberhinaus haben Nutzer oft andere Suchbegriffe als die Tag-Namen in
britischem Englisch, aber die Suche der Wiki-Software ist eher
berüchtigt. Es sei daher in den Raum gestellt, ob Schlüsselwörter zum
Suchen ("How to Map a ...") helfen könnten.

Eine erhebliche Quelle der Probleme mit Proposals ist, dass sie mit der
Beschreibung vieler Tags wechselwirken. Allenfalls sehr selten werden
die Änderungen auf alle betroffenen Tag-Definitionen nachgezogen.
Im Moment ist ein Proposal eine zusätzliche Seite im Wiki;
seinem Wesen nach ist es aber eher ein Änderungssatz ähnlich z.B. einem
Commit bei Git.


Spielregeln und deren Legitimation

Wie legitim sind Prozesse, wenn bloß eine Handvoll Personen mit der
nötigen Zeit um Mails auf der Mailingliste und Wiki-Seiten zu schreiben,
teilnehmen können? Insbesondere, wenn die Proposals zahlreiche
Widersprüche enthalten, vage bleiben oder notwendige Details offen
lassen. Dennoch sind es die Aktiven dieser Liste, die das nötige
Durchhaltevermögen gezeigt haben, damit die Dokumentation zumindest
grundliegend gepflegt bleibt. Jede Änderung zu neuen Prozessen muss sich
also daran messen, ob sie die Teilnehmer-Basis wirklich vergrößert.

Umgekehrt habe ich größtes Verständnis für Mapper, die sich Sorgen über
unabgestimmte Änderungen im Rendering oder der Editier-Software machen.
Viele dürften es wertschätzen, sobald der Prozess von der Änderung im
Wiki zur Änderung im Rendering und anderswo vollständig nachvollziehbar
ist. Die Prozesse sind nicht geheim, aber doch un- oder unterdokumentiert.

Auch hier trägt die Vielzahl der Diskussionskanäle und der mangelnde
Informationsfluss dazwischen dazu bei die Stimmung zu verderben. Noch
schlimmer: das Verhältnis zwischen Anzahl der Kanäle und Anzahl der
Aktiven bedeutet das Risiko, dass bösartige oder auch nur grob
inkompetente Teilnehmer einen der Kanäle übernehmen und erheblich zur
Verwirrung beitragen können. Gute Ideen, wie man Teilnehmern die besser
gepflegten Kanäle schmackhaft macht und einige Kanäle (z.B. die
Wiki-Diskussionsseiten) schließt können lohnen, sie zu verfolgen. Dazu
kommt, dass die History des Wiki so unzureichend gegenüber dem ist, was
Versionskontrollsysteme heute bieten, dass zu überlegen ist, wie man
Metaphern und Paradigmen von dort übernehmen könnte.

Dies wird hoffentlich helfen zu verstehen, ob und wann die Autoren der
Dokumentation und die tatsächlichen Mapper der Tags die gleiche
Bedeutung anwenden.

Viele Grüße,

Roland

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

[OSM-talk-fr] Gestion des documentation d'attributs

[Roland Olbricht]

Bonjour,

J'ai le devoir de parler de la gestion des règles des attributs sur la
SotM et j'aimerais développer cette opportunité vers quelque truc
d'utile à long terme. Pour m'assurer que je suis sur la bonne voie et
non pas involontairement après un programme personnel, j'aimerais vous
demander de commenter les résultats énumérés ci-dessous.


Insuffisant flux d'information

Bien que de nombreuses parties du projet OpenStreetMap soient bien
traduites, les documentation des attributs comportent des lacunes
importantes. Sur un échantillon aléatoire de 10 balises, le nombre de
langues déclarées varie entre 2 et 18, mais peu sont complètes et à jour
(échantillon : 2 sur 10 pour l'allemand, 3 sur 10 pour le français).

Un autre type de flux d'informations imparfait est que les définitions
des attributs peuvent être modifiées sur la page wiki longtemps après
que l'attribut soit largement utilisé.

Le cas inverse d'un attribut introduit sans aucune documentation se
produit également. Bien que cela se produise habituellement assez
lentement pour donner un sens aux données ajoutées par les utilisateurs
personels, une importation ou une édition organisée pourrait être en
mesure de décaler considérablement le sens de facto d'un attribut,
n'importe qu'elle soit largement utilisée, documentée, les deux, ou aucune.


Plus des structures requirés

Les problèmes de traduction ont été confondus avec un autre problème:
Différentes caractéristiques peuvent sembler très différentes d'une
région à l'autre. Par exemple, highway=primary et highway=unclassfied
par rapport à highway=track ont besoin d'examples différents en
Allemagne et dans les métropoles américaines, d'une part, et en Islande
ou en Afrique rurale, d'autre part. Il est facile de mélanger cela avec
la traduction dans la langue prédominante de la région, mais les défis
du attribution en Belgique, au Canada et au Niger sont sensiblement
différents, bien que les trois pays aient le français comme langue
officielle. Inversement, il n'y a aucune raison valable de modifier les
règles d'attribution dans chaque bloc de maisons à Bruxelles.

De plus, les gens ont souvent des termes de recherche différents des
noms d'attributs anglais britanniques ou de leurs traductions, et le
moteur de recherche wiki est tristement célèbre pour ses mauvaises
performances. Avoir des mots-clés explicites pour attirer l'attention
d'un mappeur sur la liste des balises éventuellement appropriées peut aider.

L'un des principaux problèmes à l'origine du concept de Proposal est le
suivant qu'il interagit avec de nombreux attributs de manière non
triviale et qu'il n'est pratiquement jamais correctement appliqué à
toutes les définitions d'attributs affectées. Une Proposal est au moment
une page supplémentaire bien qu'elle devrait avoir beaucoup plus
d'impact qu'un commit Git, en regroupant les modifications sur plusieurs
pages de définition d'attributs dans un seul groupe de modifications.


Règles et leur légitmation

Quelle légitimation a un processus si seulement une poignée de personnes
ont le temps d'écrire des mails sur une liste de diffusion et d'écrire
des pages wiki sont impliquées ? En particulier, si les propositions
finissent par être pleines de contradictions ou de termes vagues et
laissent les réponses nécessaires indéfinies. Pourtant, ce sont toujours
ces personnes qui ont fait preuve de l'endurance à long terme nécessaire
pour assurer l'entretien et qui font le travail. Par conséquent, tout
changement visant à remplacer les processus par de meilleurs processus
doit viser à élargir et non à réduire la base des responsables de la
maintenance à long terme.

Inversement, je comprends parfaitement les cartographes qui se méfient
des changements soudains dans le rendu ou l'accès aux tags dans les
logiciels d'édition. Beaucoup de gens apprécieraient probablement de
mieux comprendre ce qui se passe sur le chemin d'une discussion
d'attributs à un changement final dans le logiciel de rendu ou
d'édition. Ces processus ne sont pas secrets, mais souvent mal documentés.

Là encore, les différents canaux de discussion et le manque de flux
d'informations entre cettes contribuent à la mauvaise humeur. Pire
encore, le rapport entre les activistes et les canaux signifie que des
personnes malveillantes ou tout simplement incompétentes pourraient
facilement prendre le contrôle de certains canaux et contribuer
considérablement à la confusion. De bonnes idées sur la façon de
rediriger les gens et de fermer certains des canaux (par exemple les
pages de discussion wiki) pourraient valoir la peine d'être poursuivies.
En plus de cela, l'historique wiki est tellement moins utile que ce à
quoi les développeurs sont habitués de nos jours dans les systèmes de
contrôle de version que l'emprunt de méthaphores et de paradigmes de là
à la documentation du tag vaut la peine d'être considéré.

Cela permet, nous l'espérons, d'encourager les auteurs de la
documentation et les cartographes qui utilisent une attribut à

Re: [Talk-de] Änderungen im Wiki: Tag:public transport=platform

[Roland Olbricht]

Hallo Nzara,

da pflichte ich Martin dringend bei. Gut 99% aller Name-Nutzungen an
public_transport=platform in Deutschland sind die Namen der Station.

Ich habe das für die fünf größten Bundesländer ausgezählt:

Land Hst mit Name  Hstname  Steigref
NRW673246630466299 5
Bayern 391263409733991   106
BaWü   256732215922002   157
NDS22372204432038063
Hessen 22967214852147124

Da es eine händische Sichtung der Hstnamen ist, werde ich das auch nicht
aufs ganze Bundesgebiet ausdehnen; der Trend ist eindeutig.

Wer selber bei sich auszählen möchte, kann alle vorkommenden Namen listen:
https://overpass-turbo.eu/s/Lp4
Bitte die Bounding-Box zum Zielort schieben.

Wenn es einen Sonderwunsch gibt, kann man den gerne diskutieren. Aber er
gehört auf keinen Fall in die Tag-Dokumentation; Leser der Dokumentation
könnten das für anerkannt halten. Wenn ein Tag wie hier breite
Verwendung gefunden hat, sollte es auch auf keinen Fall umdefiniert werden.

Ich persönlich halte diesen Sonderwunsch auch nicht für sinnvoll. Ziel
muss es sein, das Arbeiten für den Mapper einfach zu halten, und da ist
es besser, wenn wir für jedes Objekt (Straße, Ladengeschäft,
Bushaltestelle, etc.) beibehalten: Name ist die Bezeichnung, die am
Schild drüber dafür steht.

Viele Grüße,

Roland

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

[Talk-de] Dokumentation zur Overpass API

[Roland Olbricht]

Hallo zusammen,

es gibt jetzt ein nutzbares Handbuch zur Overpass API
https://dev.overpass-api.de/overpass-doc/de/

Das Handbuch soll einerseits den Wunsch nach einer umfassenden
Dokumentation erfüllen, andererseits Features jenseits von schlichtem
key=value und Bounding-Box mehr Mappern zugänglich machen. Unter anderem
deswegen ist es auf Deutsch verfügbar, Englisch und Französisch werden
folgen.

Zwar befindet sich das Handbuch noch in Aufbau, aber die wichtigen
Kapitel "Einführung", "Räumliche Datenauswahl" und "Objekte finden" sind
bereits einsatzreif. Die übrigen Kapitel und Abschnitte werde ich in den
nächsten Monaten nachtragen.

Über Rückmeldung würde ich mich freuen und werde dazu den
Github-Issuetracker, die Mailingliste sowie Mails direkt an mich und
auch das Forum lesen.

Viele Grüße,

Roland

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

[Talk-GB] Displaced nodes

[Roland Olbricht]

Dear all,

there has been a couple of probably accidential movements of thousands
of nodes off central London.

The changesets in question are most likely

72980739
72980741
72980743
72980748
72980751
72980758
72980760
72980761
72980762
72980765
72980767

I'm attempting to revert them right now. As JOSM is surpringly slow on
the task, I'm happy about any help.

Best regards,

Roland

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

Re: [OSM-talk] [Osmf-talk] Anyone who likes to organize an ID discussion panel at SotM?

[Roland Olbricht]

Hi,


reading the discussions about the direction of ID development and how
the community wants the ID at the OSM website I had the idea that there
could perhaps be a panel at SotM. Does anyone want to organize an ID
discussion panel at SotM? Please tell me or us (program committee in CC)
and we can consider it. At the moment it would be sufficient to have
someone (or more) who wants to organize it. All details could be defined
later.


I volunteer to run of birds-of-a-feather on
"New processes to agree on tagging suggestions and their interaction
with the editing software available on openstreetmap.org"
(Feel free to shorten th title as you see fit).

I do not think that a tribunal on iD is helpful to anyone. Nonetheless,
mappers (and data users) would like to easily find what common sense is
for each kind of object. There is only limited support for the current
wiki and mailing list model. iD's approach earned backlash as well.

I do have 3 to 5 ideas how to lining out common sense of tagging could
be improved. I will not tell them right now: I highly value my
audience's attention, and half-baked ideas waste that precious resource.
Working on them right now, a couple of days before the SotM-FR,
jeopardizes my contribution to that conference and would waste the
attention of the audience there.

I instead suggest to collect ideas with deadline 1st of September. I
commit to present my ideas then and invite everyone to do so as well (on
this list, the wiki, or the forum, other channels if known and openly
available). This gives people not attending the conference better
chances to get involved.

That preparation ensures that we end up with one (or more) deliverables
that can be worked on. This is also the reason to prefer the BoF over a
panel discussion. I am unable to organize a panel discussion in a way
such that it produces a deliverable.

Some keywords to foster hope that there is a way forward:
- Changeset discussions as a social feature have widespread acclaim
- The "Any-Tag-You-Like" principle accompanies and serves OpenStreetMap
since more than a decade
- IETF's "Rough consensus" (RFC7282) has built the internet
- many tools already facilitate to make evidence based decisions,
  e.g. Taginfo in general and Taginfo's list of tag usage
https://taginfo.openstreetmap.org/keys/highway#projects

Best regards,

Roland

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

Re: [Talk-de] Erreichbarkeit von Adressen

[Roland Olbricht]

Hallo zusammen,


Wie hast du die Auswertung erstellt, mit Overpass turbo evtl.? Kannst du
die Abfrage bekanntgeben?


Ohne zu wissen, wie Florian das konkret gemacht hat. Es funktioniert
https://overpass-turbo.eu/s/IF0
Empfohlene Zoom-Level 13-19. Liste der Highway-Typen in Zeile 1,
Abstands-Schwellwert in Zeile 3, hier "100".

Viele Grüße,
Roland

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

Re: [OSM-talk] usefulness of brand:wikipedia and brand:wikidata tags (was Re: Bank of India (and other) Wikidata tags)

[Roland Olbricht]

Dear Andy,

I would like to use a metaphor:

If I had known that the captain of the Titanic considered the ship
unsinkable then I had not boarded the ship.
Not so much because I had been interested in the captain's belief but
because believing to be unsinkable is way too little for a contingency plan.

The contingency plan for OpenStreetMap is that everyone can still edit
the map even if the main database were the only website of the world
that is still available. This works well with a "wikipedia" tag: An
average person can, from the wording of the page title, still predict
whether an object in question qualifies for that tag or not, without the
article available at all.

This does not work with a wikidata tag.
Without the Wikidata server up and availble the tag is a random number only.

I'm not talking about who has the most reliable server here.
In practice the things that happen (and all actually have happened in
one form or another):
- A provider blocks the IP address block of a particular site because of
a policy on an adjacent IP address
- HTTPS is used and the browser or the client's library does not trust
the certificate or has a conflicting policy
- A misconfigured carrier grade NAT makes the address inaccessible
- Wikipedia or other services distinct from openstreetmap.org go on strike
- a site starts to apply or substantially reduces quotas

I do not presume the Wikidata servers had failed or to do in the
forseeable future. Serious issues always come from an unexpected
direction. The engineers of the Titanic have taken precaution for many
many things and probably simply never thought about icebergs, or not
hard enough. So please do not try to discuss the issues away.

It is nowadays an engenering virtue to decouple things enough to keep
each of the parts as simple as possible. That has saved both many lifes
as well as trillions of dollars.

That said, the free-form tagging paradigm means that it may or may not
been acceptable to add tags in addition to tags understandable without
the help of any external tool.  However, it is destructive to replace
tags understandable without any external tools with tags that require
external tools, i.e. to remove wikipedia tags in favour of wikidata tags.

Best regards,

Roland


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

Re: [OSM-talk] problems with differential update?

[Roland Olbricht]

Unzipping and re-zipping helps so it is not actually an error in the OSM
data. AFAIK both sys admins are currently unavailable so it will take a
while to fix.


There has been any problem at all here on the Overpass API instances:

I got from the server within seconds
de7bdcc5c9f8ea5ba4043d569a51ee6a  634.osc.gz
and uncompressed with gunzip
9027caf2a2f23763fb6037915997f0a1  -

The file now has
4589b5f4c11dbbe0bb504c5642c54b72  634.osc.gz
and uncompressed with gunzip
9027caf2a2f23763fb6037915997f0a1  -

Could it have been that the file triggered an arcane bug in a gz library
from the Java universe?

If you want to cross, check, I have put the files here:
https://dev.overpass-api.de/misc/de7bdcc5_634.osc.gz
https://dev.overpass-api.de/misc/4589b5f4_634.osc.gz

Roland

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

Re: [OSM-talk-fr] Overpass API en grève

[Roland Olbricht]

Bonjour,

l'Overpass API a returnée à operation normale.

Je veux remercier l'association OpenStreetMap France pour la traduction
de l'information sur la problème a
https://www.openstreetmap.fr/copyright-article-13/

Roland

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

Re: [OSM-talk] Overpass API turned off due to Upload Filter thread

[Roland Olbricht]

Hello everybody,

Overpass API is now back to normal operations. Thank you for your
understanding.

To ensure that OpenStreetMap will have a place in the future, it still
makes sense to phone (yes, phone) your member of the EP. Platforms that
assist on that are:
https://pledge2019.eu/en
https://saveyourinternet.eu/act/

If you need information on the background, I still suggest
https://www.openstreetmap.de/uf/en.html

Best regards,
Roland

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

Re: [Talk-de] Overpass API wegen Upload-Filtern temporär aus

[Roland Olbricht]

Hallo zusammen,

danke für das Verständnis und die positive Rückmeldung. Die Overpass API
ist jetzt wieder im Normalbetrieb.

Es ergibt natürlich trotzdem Sinn, weiterhin die EU-Abgeordneten
anzurufen, siehe
https://www.openstreetmap.de/uf/

Viele Grüße,

Roland

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

Re: [Talk-de] Overpass API wegen Upload-Filtern temporär aus

[Roland Olbricht]

Hallo zusammen,


Super, dass eine weiterhin funktionstüchtige Alternative eingerichtet
wurde -- leider erhalte ich dort aber nur einen 403-Fehler. Ist da
eventuell ein Konfigurationsfehler drin?


Der Zugriff z.B. mit der URL
https://overpass-api.de/no_art11art13/interpreter?data=out;
sollte funktionieren.

Je nach verwendetem Tool muss also entweder
https://overpass-api.de/no_art11art13/
als Basis-URL hinterlegt werden (z.B. bei Overpass Turbo,
"Einstellungen" > "Allgemeines") oder
https://overpass-api.de/no_art11art13/interpreter
anstelle von
https://overpass-api.de/api/interpreter
mit einem POST-Request kombiniert werden oder wie üblich die Anfrage per
GET an
https://overpass-api.de/no_art11art13/interpreter?
angehängt werden.

Viele Grüße,
Roland

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

[OSM-talk-fr] Overpass API en grève

[Roland Olbricht]

Bonjour,

le Parlement européen va voter la Proposition de directive sur le droit
d'auteur dans le marché unique numérique. Cette proposition menace
l'existence d'OpenStreetMap par des affaires juridiques tres cheres.

Les articles problematiques sont article 11 et article 13.
Un loi comme article 11 existe déja en Allemagne et Espagne.
Il a étouffé plusieur services du net en Allemagne et plusieurs éditeurs
en Espange parce-que les côut juridiques sont insurmontable pour tous
que de services très grandes et ils n'ont pas la force pour un
negotiation favorable.

Pour informer tous le monde, le service Overpass API est parmi autres
services en grève tojour jusq'au 21h (soit 20h UTC).

Si vous devez obentir des résultats normales, changez le URL a
https://overpass-api.de/no_art11art13/
Cette URL reste disponible jusq'au fin de grève cette soir.

Je suis desolée pour les désagréments. Ces sont necessaires pour avenir
de désagréments graves et permanents.

Roland

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

[OSM-talk] Overpass API turned off due to Upload Filter thread

[Roland Olbricht]

Hello everybody,

on 26th March the European parliament will vote on the Directive on
Copyright in the Digital Single Market. This directive would as a side
effect threaten the OpenStreetMap project with substantial legal and
technical burdens, see
https://www.openstreetmap.de/uf/en.html

To inform all users both about the problem and possibilities to protest
against that proposed bill, the Overpass API shows only an informative
result today. This will last until about 20:00 UTC.

If you need the usual functionality then please change temporarily to
the base URL
https://overpass-api.de/no_art11art13/
This URL remains available until the Overpass API returns to normal
operations. If you use Overpass Turbo then please change it in "Settings
> General".

I'm sorry for the inconvenience. This shall defeat much greater
inconvenience stemming from the fallout of the proposed bill.

Best regards,

Roland


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

[Talk-de] Overpass API wegen Upload-Filtern temporär aus

[Roland Olbricht]

Hallo zusammen,

am 26. März soll das EU-Parlament über eine Urheberrechtsreform
abstimmen, die als Seiteneffekt unter anderem OpenStreetMap gefährdet.
Details siehe
https://www.openstreetmap.de/uf/

Um alle Nutzer auf die Möglichkeiten zu Protesten hinzuweisen, schließen
sich mehrere OSM-Dienste einschließlich der Overpass API dem heutigen
Aktionstag an. Bei der Overpass API dauert die Unterbrechung bis ca. 21 Uhr.

Nutzer, die statt der normalen Suchergebnisse das Informationsergebnis
sehen, können die URL temporär auf
https://overpass-api.de/no_art11art13/
ändern. Diese temporäre URL wird dann mit der Wiederherstellung des
normalen Betriebs wieder abgeschaltet.

Ich bedauere die Unannehmlichkeiten, erinnere aber daran, dass dies der
Vermeidung weitaus größerer Unannehmlichkeiten dient.

Viele Grüße,

Roland

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

Re: [OSM-talk] Relation #2632934 is "killing" differential update

[Roland Olbricht]

There must have happened something ugly at versions 99 and 106:
https://overpass-turbo.eu/s/FYm


Thanks for that - yet again something useful in overpass-turbo ("make 
stat") that I had no idea existed.  Is there any documentation about it 
anywhere?  There is 
https://wiki.openstreetmap.org/wiki/Overpass_API/Overpass_QL#The_statement_make 
, but that doesn't have any useful information or give any examples.


Thank you for the feedback. The idea is laid out in
http://dev.overpass-api.de/blog/sliced_time_and_space.html
in particular
http://dev.overpass-api.de/blog/sliced_time_and_space.html#timeline
within
http://dev.overpass-api.de/blog/sliced_time_and_space.html#lrs

However, I accept that it is not so obvious how to combine the two. I'm 
sorry for all that have missed that. I have added an example on

https://wiki.openstreetmap.org/wiki/Overpass_API/Overpass_API_by_Example#Making_a_Table_of_Object_Versions

Best regards,

Roland

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

Re: [OSM-talk] Relation #2632934 is "killing" differential update

[Roland Olbricht]

Hi,

the relevant changesets are
65448087 (for version 99, created_by "upload.py v. 1") and
67093992 (for version 106, created_by "Vespucci 12.1.2.0").

I cite the user agents because the data looks like unintentionally changed that 
way.
I have left a bug report on Vespucci, see
https://github.com/MarcusWolschon/osmeditor4android/issues/859

I have not found a handle for "upload.py".

Best regards,

Roland

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

Re: [OSM-talk] Relation #2632934 is "killing" differential update

[Roland Olbricht]

Hi,

> there is a relation https://openstreetmap.org/relation/2632934, which 
> currently has 42698 members. Processing this rel with osm2pgsql fails, 
> because this value is bigger than 32737 (small int).

this is an Osmosis problem.

Nonetheless, the relation does not make sense. It is an ordinary bus route in 
Manhattan, but members hundreds of times repeated.

There must have happened something ugly at versions 99 and 106:
https://overpass-turbo.eu/s/FYm

Best regards,
Roland

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

Re: [Talk-GB] OSM augmented reality project - affordable hosting recommendations or Overpass?

[Roland Olbricht]

Hi,

As an alternative, I was wondering how acceptable it would be to use the 
Overpass API to obtain the data? Downloaded data would be cached on the 
device so for a given area, data would only need to be downloaded once.


I'm fine with such a usage. The fine print is about other issues:

- Overpass API does support GeoJSON indirectly, but GeoJSON does not 
support EPSG:3857, see

https://tools.ietf.org/html/rfc7946#section-4

To get GeoJSON I suggest

[out:json];
way(south,west,north,east)[highway];
convert link ::=::,::geom=geom();
out geom;

where (south,west,north,east) is the bounding box.

As an act of courtesy I suggest to set the "Accept-Encoding: deflate, 
gzip" header and use


[out:json];
way(south,west,north,east)[highway];
if (count(ways) < 2)
{
  convert link ::=::,::geom=geom();
  out geom;
}
else
{
  make error what="Too many ways in this bounding box";
  out;
}

This compresses the data and bails out if there are more than 2 ways 
in the bounding box, corresponding to between 1 MB and 2 MB of data. 
Overpass would happily deliver about 1 GB per user and day, but the 
users may have data plans with rather 1 GB per month.


Thanks,
Roland

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

Re: [Talk-de] Overpass Abfrage

[Roland Olbricht]

Hallo,

area[name="Rettungsdienstbereich Trier"];
out tags;

hat den folgenden Fund:

  





  

und

(
  node[amenity=nursing_home](area:3604168993);
  way[amenity=nursing_home](area:3604168993);
  relation[type=multipolygon][amenity=nursing_home](area:3604168993);
);
out count;

hat zumindest 1 Treffer. Gemäß Gegenprobe mit

node[highway=bus_stop](area:3604168993);
out count;

und 1641 Treffern spricht vieles dafür, dass rund um Trier wohl nur 1 
Objekt mit dem Tag "amenity=nursing_home" versehen ist.


Viele Grüße,
Roland


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

Re: [Talk-de] Overpass Abfrage

[Roland Olbricht]

Hi,


Was ich mich schon lange frage bzw. wünsche ist, dass auch bei anderen
Output-Formaten als CSV (also den out settings xml,json,custom,popup)
die Rückgabe-Attribute eingeschränkt werden könnten.


Grundsätzlich geht das mit "convert", hat aber gewollte Einschränkungen.
Beispiel:

(
node[amenity=nursing_home]({{bbox}});
way[amenity=nursing_home]({{bbox}});
relation[type=multipolygon][amenity=nursing_home]({{bbox}});
);
convert poi ::geom=geom(),name=t["name"];
out center;

Als Seiteneffekt kommen dann statt Objekten vom Typ z.B. "way" solche 
mit dem Tagnamen "poi" heraus. Außerdem sieht die Geometrie etwas anders 
aus. Im JSON-Modus ist die Geometrie GeoJSON-konform, im XML-Modus eine 
Übersetzung davon.


Der Grund ist, dass ich vermeiden möchte, dass jemand Tags abschneidet 
oder umschreibt und die Daten wieder hochlädt. Die Datenstrukturen 
sollten also hinreichend anders aussehen, um Wiederhochladen nach dem 
automatischen Umschreiben zu verhindern. Bei den produzierten Formaten 
ist noch Gestaltungsspielraum, so dass ich für Rückmeldung insbesondere 
zu Anwendungsfällen dankbar bin.


Mit dem Ausrufezeichen kann man noch Keys ausschalten, falls man nicht 
nur eine Positivliste möchte:


convert poi ::geom=geom(),::=::,!name;

Referenz:
https://wiki.openstreetmap.org/wiki/Overpass_API/Overpass_QL#The_statement_convert

Es gibt zwei Blogbeiträge zu dem Thema:

https://dev.overpass-api.de/blog/final_0_7_54.html
befasst sich mit convert

https://dev.overpass-api.de/blog/flat_world.html
befasst sich mit der Geometrie in diesem Zusammenhang.
Und ich ergebe nicht den Anspruch, Großkreise toll berechnen zu können, 
sondern es geht darum, wie ich abzufangen versuche, dass GeoJSON im 
Gegensatz zu OSM die Erde als flaches Rechteck betrachtet.


Viele Grüße,
Roland

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

Re: [OSM-talk] Help - how to get rid of wrong image in wiki?

[Roland Olbricht]

https://en.wikipedia.org/wiki/Lions_Gate_Bridge


The Lions Gate Bridge and Stanley Park causeway are not one-way. The 
middle lane switches direction, but there is always at least one lane in 
each direction.


https://commons.wikimedia.org/wiki/File:A1_bij_Muiderberg.jpg
is the only example I have found at all.

Note that this is referenced on
https://nl.wikipedia.org/wiki/Wisselstrook
and this is still referring to reversible lanes in general, not 
reversible streets.


Best regards,
Roland

--
Dr. Roland Olbricht

MENTZ GmbH, Am Mittelhafen 10, 48155 Münster
T: +49 (0)251 7 03 30-232, F: +49 (0)251 7 03 30-300
E: olbri...@mentz.net, www.mentz.net

Sitz der Gesellschaft: Grillparzerstraße 18, 81675 München
Geschäftsführer: Christoph Mentz, Amtsgericht München, HRB 91898

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

Re: [OSM-talk] Ground truth for non-physical objects

[Roland Olbricht]

Hi,

I would not be surprised if this was more of a rural/urban divide than a 
country divide.


We had run a building for 15 years without an official address here in 
Germany, Wuppertal (has more than 350k inhabitants):

https://www.openstreetmap.org/way/190295244

To cut the story short:

It had been a former signal box, and as such it had been under federal 
control. The local government simply had not even been allowed to assign 
an official address, because the land parcel had been exempt from its 
administration.


We've got utility supply, received post and had a phone landline. All to 
the never-offical address. The local council did naturalize the address 
once they were allowed to because the designation of the railway line's 
land changed. Similar cases can stem from:

- other laws interfering
- pending court trials
- boundaries across the premises
- human error
- internal technical requirements (Florian Lohoff's example)
- historical reasons
- acccumulating update delays
and probably more.

On another premises, the garbage collection address has been distinct 
from the signposted address, because the house had been located on a 
street corner and the utility had a meaningful idea where the trash 
collection did least degradation to general traffic. The different 
address meant a different collection schedule.


I'm pretty confident that similar cases exist in Cologne (more than 1M 
inhabitants) and Berlin (more than 5M inhabitants). I would be surprised 
not to find them all over the world.


For other types of data, I remeber at least three larger issues where 
the flow of information is reversed: the owing entity deemed its data so 
unreliable that they re-surveyed the data in OSM and copied it back to 
their database.


Best regards,

Roland

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

[Talk-de] Rein unterirdische Gebäude?

[Roland Olbricht]

Hallo zusammen,

aus der Changeset-Diskussion
https://www.openstreetmap.org/changeset/64670512
ist die Frage aufgekommen, ob eine Tiefgarage schon ein Gebäude 
darstellt, wenn die Zufahrt an einer Seite ebenerdig ist.


Erschwerend kommt hinzu, dass der Betreiber die Tiefgarage "Parkhaus" nennt.

Von der Lage her gibt es rund um das historische Bahnhofsgebäude die 
Bahngleise auf der einen Seite und einen neu angelegten Bahnhofsvorplatz 
mit Busbahnhof auf der anderen Seite. Diese sind zueinander ebenerdig. 
Das Gelände südlich des Bahnhofs liegt viel höher, das Gelände nördlich 
des Bahnhofs viel tiefer. Dementsprechend ist die Nordfront des 
Verteilgeschosses unter dem Bahnhofsvorplatz und der Tiefgarage sichtbar.


Da der Fußgängerdurchgang zwischen Bahnhofstunnel und Innenstadt somit 
ebenerdig ist, bildet dies auch die dominante Verkehrsachse.


Allerdings haben wir vergleichbare Situationen auch bei Bahndämmen in 
Köln Hbf, Essen Hbf, Frankfurt Ostbahnhof und Berlin-Friedrichstraße. 
Dort sind die Bahndämme mit Stützmauern ja ebenfalls kein Gebäude.


Ich wäre daher an Rückmeldung interessiert, wie andere die Situation 
einschätzen. Insbesondere: Gibt es eine sinnvolle Lösung, 3D-Mapping an 
solchen Hanglagen durchzuführen?


Viele Grüße,

Roland


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

Re: [OSM-talk] Feature Proposal - RFC - Mapping disputed boundaries

[Roland Olbricht]

Hi all,

a much simpler approach is to look into the respective constitution.

The Ukrainian constitution defines the state's territory in article 133. 
Other countries, like Germany do so as well, and Ireland does or has 
done so. France does not define its terriotry in the constitution, and 
the UK has AFAIK no constituation. Probably in both countires laws exist.


Thus I suggest to create a relation comprising the regions mentioned in 
that said article. It should hold the various name tags and a distinct 
tag (not "boundary", "admin_level", or "source") to indicate that it is 
a boundary according to the consitution, e.g. 
"legitimation=constitution" (and "legitimation=national_law" if not 
declared by the constitution). Countries where the constitution 
conincides with the de-facto border can just get the tag.


For Cyprus and Western Sahara, I have been unable to find the relevant 
documents. I'm cautiously optimistic that they can be modeled in the 
same way.


Given that there is at most one constiution per country, that those are 
designed to change infrequently and most countries are expected to 
conincide, this allows to add no-nonsense data without opening a can of 
worms.


Best regards,

Roland

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

Re: [Talk-de] Relation für Gebäude

[Roland Olbricht]

Hallo zusammen,


Ich arbeite gerade an Indoor-Karten und bin jetzt am Problem dran, ein gesamtes 
Gebäude herunterzuladen. Das Gebäude besteht aus einem Multipolygon für den 
Umriss und natürlich den diversen Räumen und POIs im Inneren. Das über eine 
Flächenabfrage mit Overpass oder über die einzelnen Knoten abzufragen ist, 
gelinde gesagt, hässlich und sehr fehleranfällig (beispielsweise U-Bahnen, 
Stromleitungen, Zäune an der Hauswand, etc.).

Nun wäre eine Relation, die das gesamte Gebäude einschließt, eine super Sache, 
um das gesamte Gebäude strukturiert herunterladen und verarbeiten zu können. Es 
gab bereits Proposals dazu, die Relationen definiert haben, die dafür sehr gut 
geeignet wären (beispielsweise 
https://wiki.openstreetmap.org/wiki/Proposed_features/indoor), aber die sind 
leider alle inaktiv.


Wir machen (in Absprache mit Roland Wagner von der Beuth-Hochschule, der 
SNCF und Simon Poole, der Simple-Indoor entworfen hat) seit einigen 
Jahren Indoor-Navigation. Die Vorschläge für Relationen sind aus gutem 
Grund immer wieder aufgegeben worden.


Eines der Probleme ist z.B., dass die wichtigsten Strukturen überwiegend 
ÖPNV-Anlagen sind; diese bestehen nahezu immer aus überirdischen, 
unterirdischen und ebenerdigen Anteilen. Es gibt eigentlich nie Konsens, 
was davon noch zum "Gebäude" gehört und nicht einmal wie viele Gebäude 
es sind - weder unter den OSM-Mappern, noch außerhalb von OSM auf Basis 
der Definition von Gebäude (gebautes Ding mit Dach); weder Steit darum 
noch zahlreiche Relationen pro Struktur sind da hilfreich.


Von daher wäre ich sehr interessiert zu wissen, um welches Gebäude es 
sich handelt und warum nicht schon "alles mit Tag 'level' in der 
Bounding Box/im Polygon" reicht (was in allen anderen bekannten Fällen 
funktioniert).


Viele Grüße,

Roland (in diesem Fall dienstlich)

--
Dr. Roland Olbricht

MENTZ GmbH, Am Mittelhafen 10, 48155 Münster
T: +49 (0)251 7 03 30-232, F: +49 (0)251 7 03 30-300
E: olbri...@mentz.net, www.mentz.net

Sitz der Gesellschaft: Grillparzerstraße 18, 81675 München
Geschäftsführer: Christoph Mentz, Amtsgericht München, HRB 91898

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

[OSM-talk] No access to Overpass API

[Roland Olbricht]

Dear all,

there have been repeated rumors that Overpass API is not reachable from 
everywhere. This is of course not intended from my side.


There has been the conjecture that censorship is involved. As I do see 
accesses from 214 countries (ISO 3166-2) in the world in the logfiles, I 
simply do not know who is censoring where (see below). But there have 
been incidents in the past (funnily, with an US provider), where a 
technical misconfiguration locked out people.


So if you cannot reach any or all of the domains
overpass-api.de
z.overpass-api.de
lz4.overpass-api.de
please contact me (over this list, per private mail, or the OSM messing 
interface if all else fails) to let me know. I will try my best to 
resolve the case.


Best regards,
Roland

---
A list can be found at:
https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2
Not in the logfiles are:
AI, AQ, AS, AX,
BL, BQ, BV,
CC, CK, CX,
EH, FK, FM,
GD, GQ, GS, GW,
HM, IO, KI, KP,
MH, MP, MS,
NF, NR, NU,
PM, PN, PW,
SH, SJ, ST,
TF, TK, UM, WS
With the exception of Western Sahara (EH), Equatoial Guinea (GQ), 
Guinea-Bissau (GW) and North Korea (KP), none of these countries is 
bigger than a few ten thousand inhabitants - it reasonably could be that 
just nobody is using Overpass API from there.


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

Re: [Talk-de] Gemeindegrenzen finden

[Roland Olbricht]

Hallo,

alle Gemeinden in Bayern als Tabelle:
https://overpass-turbo.eu/s/BpC

Für andere Ziele als Bayern müsste man den Eintrag hinter "area" anpassen.

Viele Grüße,

Roland


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

Re: [OSM-talk] Representing places with no housenumber

[Roland Olbricht]

Hi Christoph,


You probably have to give a real world example since i have no idea if
you want to say you have a building with a unique address consisting of
addr:street and addr:postcode (could be if there is only one building
at this street or with this postcode) or if you want to defend
pointless or non-verifiable tagging of addr:street for buildings
without a unique address.


An example from Germany:
https://www.openstreetmap.org/node/526129541
https://www.izb.fraunhofer.de/de/impressum.html

The whole campus just fills up the complete street. Hence, the street 
alone makes it already unique. I can confirm from having worked there 
that it has indeed no housenumber.


Best regards,
Roland



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

Re: [OSM-talk] "Nearby features" does no longer work:

[Roland Olbricht]

Hello,


Tryin go use [?] - feature I get "Error contacting
https://overpass-api.de/api/interpreter: "


I'm sorry for the inconvenience. The problem has been fixed. It 
essentially has been human error (my error).


I would like to thank all the people that have contacted me over various 
channels for the issue.


Best regards,

Roland

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

Re: [Talk-transit] SotM: tram network of Milano

[Roland Olbricht]

Hello everybody,

the code is public available as part of the Overpass API repository and has 
always been.
A pointer to the main file is:
https://github.com/drolbr/Overpass-API/blob/minor_issues/src/pt_diagrams/topographic.cc

I'm sorry for the confusion. "not publicly announced" shall mean that there is 
no documentation because the code never got production ready. Line separation 
works, colour selection works good enough, label placement doesn't work and is 
a hard problem. This includes line numbers.

I'm happy to answer questions to get that code to productive use.

Best regards,
Roland

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

[OSM-talk] SotM workshop about Overpass API

[Roland Olbricht]

Hello everybody,

My SotM workshop will be partly or mostly dedicated to a HowTo-and-Q 
session about Overpass API. This is an experimental format; I would like 
to test out whether this works as a workshop or not. The stuff about 
thinking outside the box of the OSM data model shall fill only a minor 
part - I can be conveyed better in writing anyway.


For this purpose, I would like to collect questions to prepare 
beforehand or get at least an idea what subjects you are interested in. 
So, even if you have no particular question, feel free to pick one or 
some topics as most interesting.


Sample topics could be, other topics are welcome as well:

Data analysis:
* How can I analyse tag distribution
* Can I mimic taginfo for my personal region and should I?
* Cross-check data models for applications whether they will work: have 
bus stops a name and what are bus stops really?


Quality assurance:
* How to track changes in my region
* How to track changes on my favourite tag
* What should I cross-check if I cannot refrain from doing a mechanical 
edit: examples "FIXME" and "operator"


Base techniques:
* How to query all elements on a specific level
* How to handle units in tag values
* What to do with the global bounding box
* Common cases for regular expressions in Overpass API

Using Overpass API from other tools:
* JOSM: things you should know
* uMap: One-Time-Imports and/or dynamic queries
* OpenLayers, Leaflet: up-to-date how-to-build a slippy overlay
* Python and other programming languages

Usage Policy
* how and when quotas are enforced
* misbehaviour they really happens

Implications of the GDPR

You can of course also pose questions live on stage. But these are 
expected to take more time and maybe get worse documented. So, as a 
courtesy to the fellow audience and those who stay at home, please 
choose your questions now and tell me.


You can answer to the list or directly to me, whatever you prefer.

Best regards,

Roland

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

Re: [OSM-talk] API a lot slower?

[Roland Olbricht]

Hi Maarten,

> Nothing special really, I was just downloading the data from a lot of 
> relations sequentially in JOSM. I downloaded relation 1360154 with its 
> members which are bus master_relations that then also load the bus 
> relations but without their contents, and then I selected all the bus 
> relations and downloaded the members (in JOSM: select all relations and 
> do "download members").

By the way: Please consider to use "Download data > from Overpass"
with the query

( rel(1360154); >>; );
out meta;

The runtime is expected to be 3 to 10 seconds, data is usually less than two 
minutes off. As a side effect, this takes load off the Main API.

Regards,
Roland


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

Re: [Talk-de] OSM + Wikidata: Wikidata property proposal fuer eine OSM node ID

[Roland Olbricht]

Hallo,

> Ob OSM "Permanent ID" bereits aus dem Experimentierstadium raus ist,
> ist mir unklar.

Auf der technischen Ebene ist die Permanent-Id seit Jahren ausgereift. 
Sie hat aber praktisch keine Akzeptanz. Die Externen suchen da nach 
einer dauerhaft vergebene Id, und weder Koordinaten nach Namen werden 
akzeptiert. Umgekehrt bereiten die OSM-Ids auch nicht soviel 
Leidensdruck, dass da jemand eine konzeptionell schwierigere Lösung 
akzeptiert.


Das Problem ist, dass alle Datenbank-Einführungen, von Relationalen 
Datenbanken bis zum Semantic Web da sehr dogmatisch sind - es wird immer 
vorausgesetzt, dass in der Dtanebank repräsentierte Objekte eine 
Identität haben. Jeder Wikidata-Aktive wird als immer aufs Neue 
argumentieren müssen, warum er für Geodaten von Ids abgerückt ist - eine 
Sisyphos-Arbeit.


Also konkreter: als OSMler muss ich bei einem Ladengeschäft nicht 
entscheiden, ob das Gebäude oder der Verkauf das relevante Objekt ist, 
und ob der Rasen vorm Haus, der Bürgersteig, der Parkplatz und weiteres 
dazugehören oder nicht. Oder ob es einen Umzug darstellt, wenn ein 
Geschäft eine Filiale eröffnet und später das Stammhaus schließt, aber 
die Filiale weiterführt.


Für die Identitätsbildung muss ich das festlegen, sonst transportiert 
die Identität nur einen Namen, und die Koordinate wäre schon die 
präzisere Information.



Ich schlage stattdessen vor, in Wikidata schlicht Koordinaten zu
nutzen - wie bisher.


Das ist, aus OSM- weil geographischer Sicht die richtige Lösung. Aber da 
steht uns die Datenbank-Dogmatik entgegen, die, wie geschrieben, 
Identität als selbstverständlich voraussetzt.


Viele Grüße,
Roland

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

[OSM-talk] Overpass API 0.7.55

[Roland Olbricht]

Dear all,

A new release of Overpass API is now available, version 0.7.55.

The core feature of this version are geometries for derived objects: We 
tell and have told since a long time to people who want to mechanical 
edit the database that they should rewrite the data on the client side. 
The long term goal for Overpass API is that we could just provide to 
such people a link through which they can consume rewritten data 
accordingly to their respective needs. With geometry on derived 
elements, we are one step closer to do so.


Beside that, further evaluators have been added and some existing have 
got improvements. The set of control structures known from full-scale 
programming languages are now available with its semantics adapted to 
the needs of OSM queries.


The details will be presented in a series of blog posts on 
https://dev.overpass-api.de/blog/ like for the previous version.


Best regards,

Roland

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

Re: [Talk-de] Overpass-Integration meldet seit kurzem "Bad-Request" ohne Code-Änderung

[Roland Olbricht]

Hallo,

auf der TüBus-Karte [1] funktioniert seit kurzem -- obwohl der Code 
nicht geändert wurde -- die Overpass-Abfrage nicht mehr. Der Request 
wird mit Status 400 beantwortet.


Weiß jemand, was sich geändert hat und was ich ändern müsste, damit die 
Abfrage wieder funktioniert?


da muss ich ich entschuldigen. Das war natürlich nicht beabsichtigt.

Es handelt sich, wie schon festgestellt, um eine Nachlässigkeit in der 
Syntax (fehlendes Semikolon). Ich bin schlicht nicht auf die Idee 
gekommen, dass das bisher funktioniert hat und dass es tatsächlich 
jemand nutzt.


Zu den neuen Version dann möglichst bald mehr Informationen. Die 
Dokumentation ist noch nicht fertig, daher ist die Version noch nicht 
angekündigt.


Viele Grüße,
Roland

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

Re: [OSM-talk] New wave of Pokémon Go mappers – check the parks

[Roland Olbricht]

Hi,

Michael, thank you for pointing to the problem. The query finds parks 
that existed already on April 23rd midnight. I think the relevant parks 
are rather those parks that have changed since that date. Thus, I 
suggest the query


[timeout:120]
[bbox:{{bbox}}];
(
 way[leisure=park];
 rel[leisure=park];
 way[leisure=garden];
 rel[leisure=garden];
 way[recreation_ground];
 rel[recreation_ground];
 way[leisure=playground];
 rel[leisure=playground];
 way[leisure=pitch];
 rel[leisure=pitch];
 way[landuse=grass];
 rel[landuse=grass];
);
(way._(newer:"2018-04-23T00:00:00Z")->.w;rel._(newer:"2018-04-23T00:00:00Z"););
out geom meta;

Best regards,
Roland

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

Re: [Talk-transit] stop_position proposal

[Roland Olbricht]

Dear all,

as a follow-up a statistic about whether highway=bus_stop is rather used 
on-street or off-street. The vast majority is (now) mapping bus stops 
off the street. The numbers vary, 99% of all bus stops in United Kingdom 
are mapped off street, about 80%-90% in France, Italy, and Germany. But 
also only 65% in Poland.


The request is per country, here "United Kingdom" as an example. Please 
change the country to your country of interest:

https://overpass-turbo.eu/s/xXp
The runtime can vary, and for Germany it is several minutes.
The important data points are the first entries on the "Data" tab.
The results visiable on the map indicate which stops the query could not 
sort as either on-the-road or off-the-road (including being on a footway 
or similar) because it could not classify the highway value as footway 
or vehicle related. highway=pedestrian is classified as vehicle way, 
because in all the examples I have checked it has been used that way:

https://overpass-turbo.eu/s/xXq

Maybe we should, rather than blurring the line between on-street and 
off-street use, make off-street the officially preferred way of mapping.


Best regards,
Roland

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

[Talk-transit] stop_position proposal

[Roland Olbricht]

Dear all,

there is another proposal, distinct from Polyglot's proposal that is in 
RFC since some days:

https://wiki.openstreetmap.org/wiki/Proposed_features/Drop_stop_positions_and_platforms

Before I tell a personal opinion, I would like to present some related 
facts. The basic idea is to look how the tags are actually used.


Taginfo tells us
http://taginfo.openstreetmap.org/keys/public_transport
that there are more platform tags than stop_position tags
and both are so many that you cannot reasonably view them all on a map.

About two thirds of elements with public_transport=platform
bear also highway=bus_stop
https://taginfo.openstreetmap.org/tags/public_transport=platform#combinations
but there are at least more than 100'000 nodes (not ways, not relations, 
hence not fully mapped platforms) that are public_transport=platform but 
not highway=bus_stop.


These are still too many to reasonably show them on a map (and to not 
talk what should happen about them). For you convenience, I have added a 
bbox limited request for those that you need to move to your area of 
interest:

https://overpass-turbo.eu/s/xWI
From my fist impression, most of them are simply not tagged with 
highway=bus_stop. However, the first hit in Rome is a tram stop that for 
a good reason is not tagged as highway=bus_stop.


It is much less compelling to retag public_transport=stop_position as 
highway=bus_stop. Less than one third of them is tagged as

https://taginfo.openstreetmap.org/tags/public_transport=stop_position#combinations
And here, many belong to railways. Again, a bbox bounded query:
https://overpass-turbo.eu/s/xWM

Another matter are definitely wrong public_transport=stop_position, 
because they are off any highway, railway, or ferry. There is a 
surprsingly large number of them. I have made an area related request 
because we need the statistics in a moment:

https://overpass-turbo.eu/s/xWF

Running this request for Germany, France, Belgium, the Netherlands, 
Austria, and Switzerland shows that more than half of all global uses of 
stop_position are in these six countries (go to "Data", read the first 
entry). This is not an arbitrary selection - all these six countries 
have about 1000 to 2000 stop_positions per million inhabitants, but for 
comparision UK has only 150 stop_positions per inhabitant.


However, the number of failures are significant, between 5% and 10% 
(with the exception of Belgium). The uneven distribution suggest that 
these relates to specific users, but the total number of users is more 
than 500, suggesting that there is a problem to explain the difference 
between stop_position and platform.


All in all, I do agree that there is definitely room for the improvement 
of public transport mapping. But making the tagging of 500'000 nodes 
deprecated and neglecting both problems with that and the more presseing 
problems is probably not a good way to go forward. Given that Ilya 
refuses for unknown reasons to read this mailing list, please discuss 
the matter on the discussion page if he wiki page.


Best regards,

Roland

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

Re: [Talk-transit] Proposal for simplification of mapping public transport

[Roland Olbricht]

Hi Polyglot,


https://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport_map_all_stops_as_nodes
I do agree that it would be easier for everyone to have one and only one 
member on the line relation per actual stop.


However, trains and sometimes also trams can have a significant length. 
Walking the full length of a train can take as long as 7 or 8 minutes. 
There are applications that send people before stepping on the train to 
the right section to have a shortest possible walk after getting off 
(search for e.g. "london tube exit routing", no link here to not 
advertise a specific one).


We render OSM useless for such applications if we force people towards 
adding fictitious nodes for trains. Please note that an easy approach 
like adding a node at the front position of the train does not bail out 
us because there are platforms that are called at in both directions of 
travel. In such cases, also the middle position of a train may vary.


Therefore I suggest to drop the node requirement and keep up the 
requirement to have only one object per stop.


A second thing for simplication: I suggest to require always a "name" 
tag on the member object or multiple "name:XX" tags if there is no 
preferred name in a multilingual setting. This way we could safely 
ignore relations for stop related objects.


When writing both a plugin for JOSM and the display tool
https://overpass-api.de/public_transport.html
it was the most frustrating part to go on a quest to find the 
appplicable name if people had hidden it in some special relation, 
including scores of new possible kinds of error if one has no or 
multiple names from multiple stop_area relations and so on. This was the 
main reason to discontinue the development.


I consider to write a proposal for the "name" requirement. Would it make 
more sense for you to instead include that in your proposal, i.e. add 
the requirement for the member object to have a "name" or multiple 
"name:XX" tags?


Best regards,
Roland


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

Re: [OSM-talk] Power Lines and topological error detection

[Roland Olbricht]

Hi,

> Various topological errors related to power lines are not detected by
> OSM editors. Monitoring the High Voltage power network for Quebec I
> often find nodes connecting crossing waterbody, highways, landuse to the
> power lines.

FWIW, you can find them with a query like
https://overpass-turbo.eu/s/wLQ

If you want to only get highways, there is still enough to do:
https://overpass-turbo.eu/s/wLR

For practical work in JOSM, you can get power lines and the connected 
objects: paste


way[power=line]({{bbox}});
node(w);
way(bn);
(._;>;);
out meta;

and choose a meaningful bounding box. Please do not do other things than 
disconnecting, because you cannot see to what the other objects are 
connected. But for disconnecting, this should be fine.


Cheers,
Roland

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

[Talk-de] Verkehrsverbund Mittelsachsen und OSM

[Roland Olbricht]

Hallo zusammen,

im Auftrag des VMS die folgende Einladung:


Herzliche Einladung zum Ideenaustausch beim VMS!

Das Gebiet des Verkehrsverbundes Mittelsachsen (VMS) umfasst die 
kreisfreie Stadt Chemnitz, den Erzgebirgskreis sowie die Landkreise 
Mittelsachsen und Zwickau. Wir planen, OSM-Daten als Routinggrundlage 
für unsere elektronische Fahrplanauskunft und als Grundlage zur 
Erstellung von pdf-Karten zu nutzen. Dieses Vorhaben soll aber nicht 
ohne Mitwirkung der Community angegangen werden. Der VMS möchte daher zu 
einem ersten Ideenaustausch einladen:



Wann: Montag, 19.02.2018, 18:00 Uhr

Wo: Verkehrsverbund Mittelsachsen GmbH, Am Rathaus 2, 09111 Chemnitz, 
Beratungsraum 4. Etage


Nach einem Vortrag zu unserem Vorhaben, würden wir gerne den Dialog mit 
euch suchen. Wenn ihr teilnehmen wollt, tragt euch bitte hier 
(https://wiki.openstreetmap.org/wiki/DE_talk:VMS_GmbH) ein, gern auch 
mit Themen, die diskutiert werden sollten.



Viele Grüße,

Roland

--
Dr. Roland Olbricht

MENTZ GmbH, Am Mittelhafen 10, 48155 Münster
T: +49 (0)251 7 03 30-232, F: +49 (0)251 7 03 30-300
E: olbri...@mentz.net, www.mentz.net

Sitz der Gesellschaft: Grillparzerstraße 18, 81675 München
Geschäftsführer: Christoph Mentz, Amtsgericht München, HRB 91898

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

[Talk-de] Relationen löschen (was: Königreich Württemberg)

[Roland Olbricht]

Hallo zusammen,

ich habe mal eine Anleitung geschrieben, damit man das gut in einem 
Changeset hinbekommen kann:


https://wiki.openstreetmap.org/wiki/DE:How_to_delete_a_relation

Da ich gerade keine löschbedürftige Relation gefunden habe, habe ich das 
Hochladen nicht ausprobiert. Von der Logik her sollte es aber gehen.


Die Seite ist gewollt im Wiki abgelegt, denn ich freue mich über 
Ergänzungen aus der tatsächlichen Erprobung.


Viele Grüße,

Roland


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

Re: [OSM-talk] Tool for tag tracking

[Roland Olbricht]

Hi Pierre,

This new query on the test server reports action=deleted when and object 
is simply modified to remove all tags.

See https://overpass-turbo.eu/s/uJ8


Thank you for pointing to this example. To get the information what has 
happened, please use [adiff:...] instead of [diff:...]. You then get 
back in the -section an element that has "visible=true" or 
"visible=false", according to whether the object got irrelevant or got 
deleted. As a drawback, Overpass Turbo then does not show the results.


I should add a paragraph for this in the documentation.

The reason for this behaviour is the underlying metaphor: Filtering for 
a specfic set of data (here: waterways in the given bounding box) means 
that all other data is disregarded, i.e. it makes no difference whether 
it exists or not.


While this is pretty irrelevant as long as you work with the plain 
filtered data, it does make an implication for a diff: there is no 
difference whether an object is newly created or just got relevant. You 
do not even intend the database engine to spend extra time on figuring 
that out. Symmetrically this means that for the extract it is irrelevant 
whether an item got deleted or just irrelevant.


Hence, the database spends no time on that in [diff:..] mode but it does 
in [adiff:..] mode.


> Should there be a an action subtype that reports either tag or geometry
> only actions ?

I would like to avoid having a large number of different actions, I 
prefer giving the information in different attribute or so. Most things 
can happen in combination, further increasing the number of actions if 
actions telled all the details. There had been an older attempt for a 
diff format with more actions, and it was a pain to work with it.


Best regards,

Roland

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

Re: [OSM-talk] Tool for tag tracking

[Roland Olbricht]

Hi,

for the sake of completeness, I would like to give a preview what is in 
the development for Overpass API:


Similar to this one


https://help.openstreetmap.org/questions/54268/search-for-objects-created-after-a-certain-date-with-overpass


you could nowadays search with https://overpass-turbo.eu/s/uF0
for all highways that have changed since the beginning of the year in 
and around Antwerp:


[diff:"2018-01-01T00:00:00Z"];
way[highway]({{bbox}});
out geom;

I suggest the "out geom" mode over recursing to the nodes. Overpass 
Turbo can handle both, but the "out geom" means that there is exactly 
one item per object in question. No unchanged nodes get involved.


The above result is bloated by objects like
https://www.openstreetmap.org/way/469659128/history
It has no change to its highway value but just lost the unrelated tag 
"horse=no".


Here comes a feature in the staging area for the next version into play. 
We do not ask for all changes but just for changes that affect the tag 
"highway": https://overpass-turbo.eu/s/uF2


[diff:"2018-01-01T00:00:00Z"];
way[highway]({{bbox}});
compare(delta:t[highway]);
out geom;
{{data:overpass,server=https://dev.overpass-api.de/api_new_feat/}}

The line "compare(delta:t[highway]);" reads as: keep only objects that 
have changed in the value "t[highway]". The last line is a directive to 
execute the query on the development server.


We could even drill down further and retrieve only objects that have 
been created or deleted: https://overpass-turbo.eu/s/uF4


[diff:"2018-01-01T00:00:00Z"];
way[highway]({{bbox}});
compare(delta:0);
out geom;
{{data:overpass,server=https://dev.overpass-api.de/api_new_feat/}}

This is admittedly hacky and the final implementation might have a more 
straightforward term. The condition for "compare" always evaluates to 
the empty string for non-existing objects. And for existing objects to 
"0" as we just have specified, hence it can tell apart existing from 
non-existing objects.


Can we separate the deleted from the created objects? Yes,
https://overpass-turbo.eu/s/uF7 delivers only created objects:

[diff:"2018-01-01T00:00:00Z"];
way[highway]({{bbox}});
compare(delta:0)
(
  way._(newer:"2018-01-01T00:00:01Z");
  out geom;
);
{{data:overpass,server=https://dev.overpass-api.de/api_new_feat/}}

And https://overpass-turbo.eu/s/uFa delivers only deleted objects:

[diff:"2018-01-01T00:00:00Z"];
way[highway]({{bbox}});
compare(delta:0)
(
  ( ._; - way._(newer:"2018-01-01T00:00:01Z"); );
  out geom;
);
{{data:overpass,server=https://dev.overpass-api.de/api_new_feat/}}

Please note that these are not yet in a published release because there 
may come up a reason to change the syntax. If that happens, I will write 
a mail here again. For example, it might be more concise to do these 
tasks with a three argument "changed" condition. But I have not 
evaluated yet whether this leads to a logically sound syntax.


Best regards,
Roland


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

Re: [Talk-de] Tagprioritaet bei OSM-Suche (historic=yes vs. man_made=*)

[Roland Olbricht]

Hoi,


wenn man in der Kartenansicht auf osm.org mit dem Fragezeichen sucht,
dann bekommt man auf der linken Seite eine Trefferliste angezeigt.
Keine Ahnung welche Softwarekomponente, die erstellt, jedenfalls wird
dort jeweils die Objektnummer und das Haupttag anzeigt, also um was
es sich grundsaetzlich handelt. Bei folgender Kombination:

man_made=water_well
historic=yes

wird ``yes'' statt ``water_well'' angezeigt.


Siehe
https://github.com/openstreetmap/openstreetmap-website/blob/7fd1e559383807dd0b509c7a08642f9d3a48616e/app/assets/javascripts/index/query.js
Zeilen 80 bis 112.

Es wird wahrscheinlich die Konfiguration aus
https://github.com/openstreetmap/openstreetmap-website/blob/e3357b27e61c3ee4f4cf51c87fdc94deeaaa7c6f/config/locales/de.yml
verwendet.

Es gibt dort unter man_made (Zeilen 715 bis 720) keinen Eintrag für 
water_well und auch sonst keine Key-Value-Kombination, die passt. Also 
wird alternativ unter den bekannten Keys für den alphabetisch ersten 
sein Wert direkt übernommen. Der alphabetisch erste ist hier "historic", 
und das hat den Wert "Yes".


Um das zu beheben, mache also bitte einen Issue auf
https://github.com/openstreetmap/openstreetmap-website
auf, dass in die Datei
openstreetmap/openstreetmap-website/config/locales/de.yml
der Eintrag "man_made: water_well: Übersetzung auf Deutsch" hinein soll. 
Den wird vermutlich jemand schließen und erklären, auf welchem Weg die 
Übersetzungen in das Repository kommen (war, glaube ich, mal Transifex 
?!?). Da müsste dann eine Übersetzung für "man_made"="water_well" auf 
Deutsch eingetragen werden.


Viele Grüße,
Roland

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

[OSM-talk] Wiki Proposals: An OSM Echo Chamber?

[Roland Olbricht]

Hi all,

We recently had an experienced and productive community member, Ilya,
putting a lot of time in a Wiki Proposal just to see the whole process 
fail. Given the feedback from the process, this has been due to a whole 
bunch of hard-to-control problems

- the whole thing has been too complex
- the wording did cause misunderstandings
- attempt to discuss the matter in an unsuitable medium

If even an experienced member cannot handle the process then we should 
reconsider whether the process of Wiki Proposals makes sense at all.


I suggest to replace the Proposal process by three more specialized
and therefore much simpler processes. They are structured by what they 
can affect.


In particular, the discussion should go to better suited places than the 
infamous Wiki page discussion shadow pages:


Ilya complained that at the wiki discussion page turned into a complete 
mess of "56K text". I do agree that the wiki page is a hard-to-read 
mess, but yet it has only the content of 10-30 messages.
There had even been expressed deprecation that the discussion spilled 
into the voting section because it is so difficult to read.


For comparison: My mail client currently handles more than 100'000 
messages and is still fast and comfortable to use. Even in the forum 
where users are stuck with what the web interface allows, it is easy to 
have discussions with some hundred responses.


This should remind us that the wiki discussion facility is unsuited for 
any nontrivial discussion but it disguises as sufficient discussion 
facility.


Note that on the same time there is a group of 350 community members
who have indicated to be interested in public transport. Ilya stated as 
a reson that the corresponding mailing list has "less than 3 messages" 
per month. The content equivalence of "3 messages" on a wiki discussion 
page already would make the impression of a heated discussion. 
Apparently the wiki discussion pages have distracted him from the real 
audience.


Please note:
It does not make sense to discuss the redesign of one communication 
channel in another communication channel. But the wiki does not have a 
suitable place to discuss the issue. Hence I cross-post to the forum to 
at least reach also a large portion of the less tech-savvy community 
members.


I suggest the following three specialized replacements for the Proposal 
process:


=== Distinguished Documentation ===

OSM could profit in a lot of cases from a good how-to map for particular 
subjects. But at the same time exists poor documentation and people do 
not necessary know which to trust. Writing a good documentation will 
become more rewarding if we can offer a process to indicate general 
acclaim and distinguish excellent documentation.


The voting confirms that the claims of the documentation reflect actual 
mapping practice. That way, it makes the effort a distinguished 
documentation.


It des not affect any existing wiki pages.
It does not affect the OSM database.

=== Wiki Cleanup ===

Amongst the real problems of OSM is that our wiki documentation has lots 
of poorly maintained pages. There exist even contradictions between 
different pages. For an unexperienced users it is difficult to figure 
out which wiki pages are really applicable.


We need a decision process which of the contradictive statements can be 
discarded. The hurdles should not be too high because we generally do 
have too few maintenance of the wiki content. Nonetheless, as this does 
give some rulesets a spin in favour of others, it should be subject to a 
voting.


There should be left a success notice after the cleanup has actually 
been done.


The document must state which wiki pages are considered authoriative.
It should state which wiki pages are to be changed.
It can list the used tags, tagging combinations, or data constellations 
that are in scope of the document at all.
It should state which used tags, tagging combinations, or data 
constellations will after the change newly contradict the wiki.


Affects the wiki.
Does not affect the OSM database.

=== Tag Disambiguation ===

Sometimes different people tag different types of objects with the same 
tags. This is a problem because you do no longer know what is really 
there. It is the core concern of the old Proposal process.

Given that backwards compatbility is nowadays an important virtue,
the preferred solution is to add an extra tag to distinguish the 
different situations.


The voting is to check that the disambiguation is logically sound
and that it covers the vast majority of applicable constellations.

Affects the wiki: the description of the affected tags and tag 
combinations are changed.
Affect the OSM database: mappers are adviced to systematically change 
tags in the course of local maintenance.


=== Remarks ===

There are other purposes advertised on the pages of the Proposal 
process. Most notably an invitation for general discussion.


I do discourage them.
From all the 

Re: [Talk-GB] pub defined as a relation

[Roland Olbricht]

While i'm here, can anyone tell me why 
http://overpass-turbo.eu/s/szG does not return nodes and 
ways-and-their-nodes? It is very similar to the example


Thank you for asking. As I will explain below, this is an opportunity to 
improve the documentation.



area[name="Brighton and Hove"][admin_level=6];
(
   node(area)[amenity=pub];
   way(area)[amenity=pub];
);
(._;>;);
out body;


In line 3 we have only nodes as a result. In line 4, we ask for ways 
that are inside the areas from the previous result (the one from line 
3). Thus, line 4 can never have a result.


Hence, please change it to

area[name="Brighton and Hove"][admin_level=6]->.a;
(
   node(area.a)[amenity=pub];
   way(area.a)[amenity=pub];
);
(._;>;);
out body;

This way, we store the result of line 1 in a set named "a". And in lines 
3 and 4 we now ask for nodes resp. ways that are in areas from "a". "a" 
could be an arbitrary name (composed of letters, digits, and 
underscores, starting with a letter; names are case sesitive).


By the way, I suggest to replace lines 5 and 6:

area[name="Brighton and Hove"][admin_level=6]->.a;
(
   node(area.a)[amenity=pub];
   way(area.a)[amenity=pub];
);
out center;

This makes both nodes and ways into a point with a single location. For 
the purpose of viewing the objects in Overpass Turbo, this means you 
need to transfer and process fewer data.


I thought there were an explanation at
http://wiki.openstreetmap.org/wiki/Overpass_API/Overpass_API_by_Example
but it isn't. I will add the example and the explanation there.

For the question whether it was different before: No. I am a strong 
proponent of backwards compatibility. It will rarely or never happen 
that I change existing language semantics.


- Roland

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

Re: [OSM-talk] Could we just pause any wikidata edits for a month or two?

[Roland Olbricht]

But what you are saying is very strange if I 
understood you correctly.  What I read here is that the only people 
allowed to fix things are those that know ALL tags and their meaning.


See 
https://wiki.openstreetmap.org/wiki/Welcome_to_Wikipedia_users#Original_research_always_wins


Or similar statements on
https://wiki.openstreetmap.org/wiki/Getting_Involved#Working_on_the_map
https://wiki.openstreetmap.org/wiki/Good_practice#Map_what.27s_on_the_ground
https://wiki.openstreetmap.org/wiki/Disputes#On_the_Ground_Rule

It is the local knowledge that matters. Tomas does know what it looks 
like there, and deems the wikipedia link correct. This is in line with 
similar cases like the mentioned distinction Aldi Nord/Aldi Süd and other.


We expect you to assure that the tool is used only (or almost only) in 
cases where the user has local knowledge, i.e. has been there, 
physically, in person. Otherwise the tool is considered a disguised bot, 
no matter how it is dressed.


Best regards,

Roland

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

Re: [OSM-talk] Could we just pause any wikidata edits for a month or two?

[Roland Olbricht]

So, to sum up:
1) There was a link to disambiguation page that no one has corrected 
until it was detected by Yuri's tool.
2) User kartonage has wrongly linked "Žagarės I piliakalnis" to "Žagarės 
II piliakalnis" in Wikipedia.
3) You have reverted it back to disambiguation link and no wikidata=* 
tag even though there is an established ground truth in the form of big 
information tables in front of each of those hillforts with names 
"Žagarės piliakalnis I" and "Žagarės piliakalnis II" in big letters.


No, that is plain wrong.
I sum it up more correctly:

Up to version #4 of http://www.openstreetmap.org/node/1717783246/history
that object had a useful wikipedia link for a human being.
An average humans can cope with a disambiguation page like this.

Version #5 broke that wikipedia link. Given the changeset comment, this 
was apparently due to a faulty wikidata link.


Version #6 reinstated a useful wikipedia link for a human being. Linking 
to the currently matching Wikipedia page might have been even better, 
but it is up to a local mapper to decide whether the page title of the 
Wikipedia page title reasonably matches the OSM object.


To avoid having the same problem again, the wikidata tag has been 
dropped in that version.


Best regards,

Roland

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

Re: [Talk-GB] Barriers and PRoWs

[Roland Olbricht]

Hi Bob,

I'm sorry or the late answer. I'm currently not at home. Thus, I'm 
reading emails less frequent.


could the barrier locations be 
shown on the ways to which they relate in the case of /> 1. to identify 
PRoWs having stiles/?


Yes, that is a useful idea. I suggest
http://overpass-turbo.eu/s/smx

There is essentially an extra output command.

Best regards,

Roland

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

Re: [Talk-GB] Barriers and PRoWs

[Roland Olbricht]

Hi all,


I should be most grateful for assistance in achieving the following

> 3. to obtain such results for an individual civil parish, either by
> selecting those ways within an admin level 10 boundary named
> "Checkendon", say, or selecting those PRoWs whose prow_ref value
> contains "Checkendon"

For the sake of simplicity, all the follwoing examples are based on the 
area spanned by teh object tagged with name="Checkendon" and 
admin_levlel=10. Feel free to play with the values - what the link 
points at is not changed by editing the query.



1. to identify PRoWs having stiles


https://overpass-turbo.eu/s/sh7


2. to invert and obtain PRoWs not having stiles


https://overpass-turbo.eu/s/sh8


4. to be able to export such results to a tabular form


I'm not sure which columns such a table should have. I have made an 
example where way id, value of prow_ref, and if barriers are present are 
columns:

https://overpass-turbo.eu/s/sh9

Best regards,

Roland

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

Re: [OSM-talk] All the subway systems in the world

[Roland Olbricht]

Hi,

I strongly suggest to oppose the proposal. To do so, you need to add

{{vote|no}} --[[User:|]] date

under the headline == Voting == once voting is opened. Said in short:
Adding more contradictions and confusion in public transport mapping 
makes a too complex topic worse in terms of complexity.


In detail, there is a whole bunch of reasons

- The proposal conflicts with well-established mapping rules. The tag
  "layer" is explicitly not to use on railway stations, as
  https://wiki.openstreetmap.org/wiki/Key:layer tells:

  "Ways in buildings (or similar structures like multilevel parking
   lots, shopping centers, airports, railway stations, some
   multilevel bridges and roads...) should be mostly described with
   level=* instead of layer."

- The proposal conflicts with reality. It requires a tag "colour" on
  lines, but not all lines have a defined colour. Making colour required
  may lead mappers to add fictitious information.

  Other examples where the proposal is at odds with reality is that most
  subway platforms in the world are on level -2, some on -3. Also,
  stop positions are not necessarily meaningful on networks with varying
  train lengths.

- There are already a couple of established mapping instructions, namely
  https://wiki.openstreetmap.org/wiki/Simple_Indoor_Tagging
  https://wiki.openstreetmap.org/wiki/Public_transport
  with details like
https://wiki.openstreetmap.org/wiki/Tag:public_transport%3Dplatform
  https://wiki.openstreetmap.org/wiki/OpenRailwayMap/Tagging
  https://wiki.openstreetmap.org/wiki/OpenStationMap#Level_of_Details

  Hence, yet another standard makes things more complicated.

- The author actively avoids discussion:

  The proposal has been announced much later (2017-09-30) than it was
  opened (2017-09-23). It has not been announced at all on the relevant
  mailing list (talk-transit).

  Even on comments on the wiki discussion page, only part of them have
  been adressed.

All in all I suggest to retract the proposal and rather write a simple 
set of instructions based on the existing wiki pages, with the errors in 
this proposal then fixed.


I still do think that Ilya has good intent, and probably the intent was 
to have a documentation what maps.me and/or the "validator" recognizes. 
But making a wiki proposal is the wrong way to do so, in particular 
given that the software still has the mentioned flaws.


Best regards,

Roland

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

Re: [OSM-talk] Draft Trademark Policy

[Roland Olbricht]

Hi Simon,

I appreciate that you have in the past helped to smoothen so much of the 
law bureaucracy that OpenStreetMap cannot avoid.


> It obviously wasn't to complicated and required lawyers to register the
> domain names in the first place and as the FAQ says we are only asking
> for the domainnames to be de-registered or given to the OSMF when they
> are no longer used for OpenStreetMap related purposes.

The problem is that the policy does nowhere restrict itself to 
domainnames. At the moment, a braindead lawyer/judge combination could 
harm your on using a file with file name extension "osm" were the 
Trademark policy to come into effect.


Would you mind to make the following change:

- Amend chapter 1 with a section 1.6

1.6 Use of the wordmarks

The term "use of the wordmarks" is restricted to incorporating the
wordmarks as part of a second level domain name. Other uses, in
particular as a reference to the OpenStreetMap project, for
attribution purposes and purely descriptive usage and Fair Use
are always granted without explicit permission.

Different from that, we assume that using the logos is never for
attribution or descriptive purposes and therefore requires a license
if stated so in this document.

This makes clear that neither the file name extension "osm" is 
jeoparday. Or you do not want to discourage people from using "osmium", 
"osmosis" or a range of other software.


Or to fear that the license is not free at all
- using the data requires attribution
- whether attribution is already a trademark infringe is at the OSMF 
capriciousness


Best regards,

Roland

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

Re: [Talk-de] Public transport V2: wie Fahrt-Nr. zu einer Ref angeben?

[Roland Olbricht]

; Toni
>>
>>
>> Am 21.06.2017 um 11:53 schrieb Dietmar:
>>> Hallo,
>>>
>>> bei den Augsburger Verkehrsbetrieben (AVV) werden im Linienplan neben
>>> der Ref. für die Buslinie noch für jede Verbindung eine Fahrt-Nr.
>>> angegeben.
>>>
>>> Für jeden unterschiedlichen Strecken- und/oder Stopverlauf wurde eine
>>> Relation angelegt und bisher wird nur im Tag note.de die Fahrt-Nr.
>>> gespeichert. Die eine ausgewählte Fahrt-Nr. steht stellvertretend für
>>> meist mehrere Fahrt-Nr.
>>>
>>> Wie soll die Fahrt-Nr. getaggt werden (ich würde dann im Value die
>>> gesamten Fahrt-Nr. mit ; getrennt auflisten)? Sie ist eine Unterordnung
>>> von ref. Nur in Kombination von Ref und der Fahrt-Nr. könnte eine
>>> externe Anwendung die richtige Relation auswählen (oder durch gesamte
>>> Analyse der Stops, aber das auch nicht eindeutig).
>>>
>>> viele Grüße
>>>
>>> Dietmar
>>>
>>
>> ___
>> Talk-de mailing list
>> Talk-de@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-de



--
Dr. Roland Olbricht

MENTZ GmbH, Am Mittelhafen 10, 48155 Münster
T: +49 (0)251 7 03 30-232, F: +49 (0)251 7 03 30-300
E: olbri...@mentz.net, www.mentz.net

Sitz der Gesellschaft: Grillparzerstraße 18, 81675 München
Geschäftsführer: Christoph Mentz, Amtsgericht München, HRB 91898

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

Re: [Talk-de] Nutzung von building:part durch Mentz GmbH

[Roland Olbricht]

Hallo Tobias,

danke für den Hinweis. Zum Wiki ist orgendwie wohl bei keinem eine 
Benachrichtigung angekommen.



mir ist aufgefallen, dass Mentz beim Bahnhofsmapping eine inkompatible
Interpretation des Schlüssels building:part gewählt hat.


Generell brauchen wir von Aufzügen zwei Objekte:
- der Aufzug selbst, der für das Routing angibt, in welcher Etage auf 
welcher Seite überhaupt Türen sind

- die Aufzugfläche. Diese zeigt an, welchen Raum der Aufzug einnimmt.

Nun haben Aufzüge immer ein Dach. Nach oben offene Aufzüge sind mir 
(zumindest im ÖPNV-Umfeld) noch nicht begegnet. Daher befindet sich ein 
Aufzugschacht immer in einem Gebäude oder bildet selbst ein Gebäude (per 
Definition eine von Menschen errichtete Struktur mit Dach).


Der Prototyp aller Aufzüge ist aus unserer Sicht immer der Aufzug in Lehel:
https://wiki.openstreetmap.org/wiki/File:M%C3%BCnchen_Lehel_Lift.jpg
http://www.openstreetmap.org/way/305665757

Dass die Struktur ein Dach hat, dürfte zweifelsfrei sein. Auch, dass sie 
so prägend für das Bild des Platzes ist, dass sie im 3D-Rendering zu 
sehen sein sollte. Es bleibt die Frage, ob jetzt der Aufzug alleine das 
Gebäude ist oder ob die U-Bahn-Station insgesamt ein Gebäude bildet.


Letzlich würde ich aus der Rückfrage den Vorschlag ableiten, dass
- wir einen Stationsumriss mit building=subway_station zeichnen, wenn 
die Station in der Gesamtheit ein Gebäude bildet. Dann bekommt der 
Aufzugschacht building:part=yes.

- wir ansonsten den Aufzug als building=elevator eintragen

Für die Stockwerke ist der Verweis auf building:part auch für mich etwas 
verwirrend. Ich muss mal herausfinden, ob wir das überhaupt für etwas 
brauchen. Eigentlich sollte indoor=yes reichen.


Viele Grüße,

Roland

--
Dr. Roland Olbricht

MENTZ GmbH, Am Mittelhafen 10, 48155 Münster
T: +49 (0)251 7 03 30-232, F: +49 (0)251 7 03 30-300
E: olbri...@mentz.net, www.mentz.net

Sitz der Gesellschaft: Grillparzerstraße 18, 81675 München
Geschäftsführer: Christoph Mentz, Amtsgericht München, HRB 91898

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

Re: [OSM-talk] HDYC, login requirement and "privacy"

[Roland Olbricht]

Hi,

because the whole issue alao affects Overpass API, I have written down 
my thoughts in a blog post:

http://dev.overpass-api.de/blog/fahrenheit_451.html

Best regards,

Roland


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

Re: [OSM-talk] Finding duplicate cycleways

[Roland Olbricht]

http://overpass-turbo.eu/s/oEm


Thank you for the link.


Unfortunately it does not (yet)catch also the segregated and
not-segregated foot-cycle-paths that are tagged using the JOSM presets
(highway=path, foot=designated, bicycle=designated, segregated=yes|no)


http://overpass-turbo.eu/s/oG6

I have essentially just added the conditions you mention in one line. I 
have slightly changed the viewport to have relevant results for the 
change within the viewport.


> I am not an Overpass-Turbo expert and don't dare to add them to your
> script

The linked queries are immutable. If you open the link then you always 
work on an independend copy.


Cheers,

Roland


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

Re: [OSM-talk] Coordinates in OSM. Really annoying

[Roland Olbricht]

Hi,


Is there /really/ any need for *six* coordinate formats? It's hard
enough to learn a new process without basics like this tripping you up.


There is nobody who is trusted enough to set an universal standard:
https://xkcd.com/927/

Basically, there is an ISO standard
https://en.wikipedia.org/wiki/ISO_6709
to have latitude before longitude. Leaflet complies, OpenLayers does not.

This is for historical reasons. When multiple projections were 
commonplace as exchange formats, then they often used x and y as names 
for the two numbers, and x often decoded to something loosely or tightly 
related to longitude.


However, OpenLayers is too useful to be thrown out just for having the 
wrong coordinate order. The same applies to a lot of other tools with 
legacy coordinate order.


To have a gentle pressure towards the ISO standard, the advertised 
interface is latitude-longitude. There are some precautions for inert 
legacy tools:

http://dev.overpass-api.de/blog/bounding_boxes.html#lonlat_bbox

As Lester has pointed out, XML requires explicit parameter names. By the 
way, I am not aware of anybody actively using the XML syntax. You can 
safely ignore that.


For the delimiter question: There are programming languages with a 
combined market share of almost 90% that agree to have to semanticy in 
whitespace. The sole widespread-used exception is Python. Once again: 
Are you seriously asking the OSM community for a crusade to throw out 
Python for minor syntactic infrigement?


Beside Python, the delimiters are always commas and semi-colons. As 
commas tend to be used to delimit parameters, they are for the numbers 
of the bounding box the delimiters of choice.


Cheers,

Roland


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

Re: [OSM-talk] Follow up on last summer discussion about the Automated Edits Code of Conduct and the DWG

[Roland Olbricht]

Hi,


Here you will find an approximate/subjective summary + some thoughts +
some proposals :

https://wiki.openstreetmap.org/wiki/User:Tuxayo/Automated_edits_code_of_conduct_and_DWG:_Mailing_list_discussion_summary_and_proposals


Thank you for keeping track of the issue. But I deem the summary 
reflects neither the current situation nor the fidings of the discussion.


Some key points:

* There is no consent on what an automated edit is or not.

It is pretty clear that your example (changing all phone~"^http://; to 
"https://; worldwide) is an automated edit. The grey cases are things 
like the French buildings import, the MapRoulette challenge in the 
Antartic region, and even the edit without local knowledge of Passau 
main station (hence a pretty small changeset) of our company.


All of these edits have at least made some data worse and have therefore 
been discussed and partly fixed, partly kept for a reason. The fact that 
the word "automated" did cause confusion gave rise to the

https://wiki.openstreetmap.org/wiki/Organized_Editing_Policy

The two extreme positions are
- Any edit without local knowledge is by its nature flawed.
- We regulate only edits run by a bot.

I personally (or we as a company) do not endorse any of the two extremes.

They key point is that to be productive you should:
- define and publish your own criterion (e.g. one of
-- changesets of unusual large extent
-- unusual high activity per tag and day
-- changesets having "revert" in their comment)
- give it a specific name and set up a watch tool for it

* The DWG is not so special as you might think

The DWG members are indeed special in dedicating huge amounts of time to 
fix human misbehaviour, and we should be grateful for that. The DWGs job 
is communication, not pushing around data.


Most of the actual reverting is done by mappers outside the DWG. Also, 
DWG members do not have any special rights. Moderation (and possibly 
redaction) is essentially done by the sysadmins, not the DWG.


I agree that from outside, the DWG activity is hard to judge. The 
problem here is that nobody has found a magic solution how to make DWG 
activity public without asking the DWG for substantially more work, 
damaging the reputation of involved mappers, or both.



I therefore would suggest to make clear-cut rules:

a) If you can decide freely what to map, where to map, and how to map 
then OSM will trust all your edits that are based on local survey. Happy 
mapping!


b) If you are directed by an organization (regardless whether you are 
paid or voluntary) then use a dedicated account and put a line on your 
user profile, e.g.:

http://www.openstreetmap.org/user/drolbr_mdv
That organization should have a corresponding Wiki page, e.g.:
http://wiki.openstreetmap.org/wiki/MENTZ_GmbH

c) If you run a software where you do not approve as a human every 
individual edit (every single change of a tag or change in geometry or 
topology) then you need to follow the Automated Edits Code of Conduct

https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct

This still leaves open the case of Armchair Mapping of all shades. An 
example with net benefit for OSM is MapRoulette. Therefore I would 
suggest to ask Martijn first for his best practices and then start to 
make rules on that.


Best regards,

Roland

--
Dr. Roland Olbricht
MENTZ GmbH, Am Mittelhafen 10, 48155 Münster
T: +49 (0)251 7 03 30-232, F: +49 (0)251 7 03 30-300
E: olbri...@mentz.net, www.mentz.net

Sitz der Gesellschaft:
Grillparzerstraße 18, 81675 München
Geschäftsführer Dr.-Ing. Hans-J. Mentz
Amtsgericht München, HRB 91898

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

Re: [OSM-talk] New Overpass API v0.7.54 version

[Roland Olbricht]

Hello everybody,

the blog
http://dev.overpass-api.de/blog/
has not only new entries but now also an RSS feed:
http://dev.overpass-api.de/blog/rss.xml

Cheers,

Roland


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

Re: [OSM-talk] New Overpass API v0.7.54 version

[Roland Olbricht]

Hello everybody,

the next blog post is now online:
http://dev.overpass-api.de/blog/index.html

I will add further post once per week Monday evening without further notice.

Cheers,

Roland


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

[OSM-talk] New Overpass API v0.7.54 version

[Roland Olbricht]

Dear all,

a new version of Overpass API is now available. It has already been 
rolled out on a the production server.


There are release notes on the releases page in the wiki:
http://wiki.openstreetmap.org/wiki/Overpass_API/versions

As the new features are quite a lot, I will present them over the next 
weeks in a dedicated blog:

http://dev.overpass-api.de/blog/

Best regards,

Roland

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

Re: [Talk-GB] Turbo Overpass Help

[Roland Olbricht]

Hi


As part of the cleanup and refresh of NaPTAN data in the West Midlands
we need to identify any bus stope nodes that were added in the old
manner i.e as a node on the highway rather than as a separate node to
the side.

Is this possible in turbo overpass?  It's  defeated me so far! Any help
appreciated


Please have a look at
http://overpass-turbo.eu/s/lJk

This chooses all nodes with highway=bus_stop that are also part of a way 
with a highway tag whose value contains motorway, trunk, primary, and so on.


Useful variants might be
- use of "West Midlands" instead of Birmingham as area name
- use "out meta" instead of "out" to get the metadata as well
- prepend the query with a line 
"[out:csv(::lat,::lon,::timestamp,::user,name)];"
to see a condensed table that tells you whether any of these stops have 
seen recent updates.


Regards

Roland

--
Dr. Roland Olbricht
MENTZ GmbH, Am Mittelhafen 10, 48155 Münster
T: +49 (0)251 7 03 30-232, F: +49 (0)251 7 03 30-300
E: olbri...@mentz.net, www.mentz.net

Sitz der Gesellschaft:
Grillparzerstraße 18, 81675 München
Geschäftsführer Dr.-Ing. Hans-J. Mentz
Amtsgericht München, HRB 91898

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

Re: [Talk-de] JOSM - mehr Speicher

[Roland Olbricht]

Hi,

generell lässt sich das am besten mit dem JAR-File bewerkstelligen, für 
WebStart ist mir keine Lösung bekannt.



Wie kann ich JOSM sagen, dass er gern 1..2 GB benutzen darf?
beim Start? in den Einstellungen? wie?

[..]

java -Xmx2048M -jar "josm-latest.jar"


Dies funktioniert auf Betriebssystemen mit vollwertiger Kommandozeile.
Viele Computernutzer sind aber dazu gezwungen, auf Windows zu arbeiten.
Weil wir das Problem hier auch unter Windows hatten:

- stelle sicher, dass Du 64-Bit-Java benutzt. 32-Bit-Java kann keine 2 
GB RAM, sondern nur etwa 1 GB (genaue Grenze unklar, Betriebssystem 
minus Java-VM)


- baue Dir eine Datei josm.bat, die im gleichen Verzeichnis wie 
josm-latest.jar liegt und die Zeile


C:\Pfad\zu\java.exe -Xmx20148M -jar "josm-latest.jar"

enthält. Dabei muss Pfad\zu ersetzt werden durch den tatsächlichen Pfad; 
bei mir auf dem Dienstrechner liegt im Download-Verzeichnis:


"C:\Program Files (x86)\Java\jre7\bin\java.exe" -jar "josm-tested.jar"

Grüße
Roland

--
Dr. Roland Olbricht
MENTZ GmbH, Am Mittelhafen 10, 48155 Münster
T: +49 (0)251 7 03 30-232, F: +49 (0)251 7 03 30-300
E: olbri...@mentz.net, www.mentz.net

Sitz der Gesellschaft:
Grillparzerstraße 18, 81675 München
Geschäftsführer Dr.-Ing. Hans-J. Mentz
Amtsgericht München, HRB 91898

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

[Talk-de] Mechanischer Edit: Tag-Anpassung

[Roland Olbricht]

Hallo zusammen,

thematisch gehört es auf die Liste nahverkehr@, aber aus 
Sichtbarkeitsgründen auch einmalig an talk-de@.


Im Nachgang zu
https://forum.openstreetmap.org/viewtopic.php?id=54210
würde ich gerne

- alle Vorkommen von "entrance:light"="yes" auf
"entrance_marker:s-train"="yes" ändern
- alle Vorkommen von "entrance:subway"="yes" auf 
"entrance_marker:subway"="yes" ändern

- alle Vorkommen von "entrance:tram"="yes" auf
"entrance_marker:tram"="yes" ändern
- alle Vorkommen von "entrance:train"="yes" auf 
"entrance_marker:train"="yes" ändern


Ich werde mich jeweils vergewissern, dass das Tag zumindest zum Eingang 
eines Bahnhofs gehört, der in Deutschland liegt und an dem die 
betreffenden Verkehrsmittel (nach Auffassung des Bahnhofsbetreibers) 
auch verkehren. Das es sich um Bahnhöfe in Großstädten handelt, habe ich 
oft Ortskenntnis, wenn auch bis zu 10 Jahre alt.


Was ich bei diesem Edit nicht prüfen würde, ist ob das Schild kürzlich 
wegvandaliert wurde oder ähnliches. Insofern ist es ein Mechanical Edit.


Viele Grüße,

Roland
(dienstlich)

--
Dr. Roland Olbricht
MENTZ GmbH, Am Mittelhafen 10, 48155 Münster
T: +49 (0)251 7 03 30-232, F: +49 (0)251 7 03 30-300
E: olbri...@mentz.net, www.mentz.net

Sitz der Gesellschaft:
Grillparzerstraße 18, 81675 München
Geschäftsführer Dr.-Ing. Hans-J. Mentz
Amtsgericht München, HRB 91898

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

Re: [Talk-de] 20 City-Zonen in Westfalen

[Roland Olbricht]

Hallo zusammen,


gibt es Wünsche, wie wir die Tarifgebiete im künftigen Westfalentarif
taggen sollen?


Nachdem jetzt über einge Tage keine weitere Rückmeldung gekommen ist, 
würden wir den Vorschlag von Nakaner aufgreifen. Die Gemeinde-gleichen 
Tarifgebiete als kopierte Relationen und die Gemeinde-abweichenden 
Relationen als eigens gemappte Multipolygone.


Den Vorschlag mit den Shapefiles von Thomas kann ich nachvollziehen, wir 
werden ihn aber nicht weiterverfolgen können.


Aus Geo-Sicht sind Shapefiles vertraut. Aber aus VU-Sicht muss ich dann 
den Sachbearbeiter, der die Geografie unter Umständen als 
Nur-Teilaufgabe miterledigt, auch ein Tool für Shapefiles bekommen, 
darin geschult werden und wir müssen Support dafür leisten, obwohl alle 
übrigen Aufgaben mit JOSM gehen. Auch das ist dann eher mit Kanonen auf 
Spatzen geschossen.


Viele Grüße,

Roland

--
Dr. Roland Olbricht
MENTZ GmbH, Am Mittelhafen 10, 48155 Münster
T: +49 (0)251 7 03 30-232, F: +49 (0)251 7 03 30-300
E: olbri...@mentz.net, www.mentz.net

Sitz der Gesellschaft:
Grillparzerstraße 18, 81675 München
Geschäftsführer Dr.-Ing. Hans-J. Mentz
Amtsgericht München, HRB 91898

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

[Talk-de] 20 City-Zonen in Westfalen

[Roland Olbricht]

Hallo zusammen,

gibt es Wünsche, wie wir die Tarifgebiete im künftigen Westfalentarif 
taggen sollen?


Ab August 2017 wird in Westfalen ein neuer Gemeinschaftstarif 
eingeführt. Um Fragen für die Zugänglichkeit als Open Data der 
Tarifzonen gleich im Ansatz zu lösen, überlegen die beteiligten Städte 
und Kreise bzw. Verkehrsunternehmen, die Geographie direkt in OSM 
einzutragen.


Bei den meisten der 300 Tarifzonen gibt es dazu nichts zu tun, weil sie 
mit den Gemeindegrenzen identisch sind. Rund 20 Tarifzonen weichen aber 
davon ab, entweder als Sammlung von Stadtteilen oder als Straßenliste. 
Details habe ich noch nicht.


Wir würden daher gerne den Sachbearbeitern eine Empfehlung zum Taggen 
geben. Bisher würde ich dazu neigen


- an bestehenden Gemeindegrenzen ein Tag "westfalentarif:zone"= 
zu ergänzen


- bei den 20 abweichenden Tarifgebieten jeweils ein Multipolygon 
möglichst unter Nutzung bestehender Grenz-Ways mit

-- type=boundary
-- boundary=public_transport
-- westfalentarif:zone=
anzulegen.

Zur Unterstützung der Themenstruktur für die Mailinglisten rege ich an, 
das auf der nahverkehr@-Liste zu diskutieren. Gerne kann jemand auch im 
Forum darauf hinweisen, dann böte es sich an, den Link hier zu posten.


Viele Grüße,

Roland (dienstlich)

--
Dr. Roland Olbricht
MENTZ GmbH, Am Mittelhafen 10, 48155 Münster
T: +49 (0)251 7 03 30-232, F: +49 (0)251 7 03 30-300
E: olbri...@mentz.net, www.mentz.net

Sitz der Gesellschaft:
Grillparzerstraße 18, 81675 München
Geschäftsführer Dr.-Ing. Hans-J. Mentz
Amtsgericht München, HRB 91898

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

[OSM-talk] Overhaul of https://wiki.openstreetmap.org/wiki/Use_OpenStreetMap

[Roland Olbricht]

Hello everybody,

I would like to overhaul one of the second level landing pages in the wiki
https://wiki.openstreetmap.org/wiki/Use_OpenStreetMap

The main reason is that I've found a forum thread with a completely 
misinformed user

https://forum.openstreetmap.org/viewtopic.php?id=56469
When trying to send a proper link to our documentation, I have realized 
that indeed the wiki leaves a newbie seeking data no way to find how to 
access it.


For this reason I would like to add back the links to
https://wiki.openstreetmap.org/wiki/Download
that used to be on the front page.

To avoid disturbing a second level landing page, I have made a mock-up
https://wiki.openstreetmap.org/wiki/User:Roland.olbricht/Use_OSM

Please feel free to discuss it on the wiki
https://wiki.openstreetmap.org/wiki/Talk:Use_OpenStreetMap

I suggest to move the mock-up to the real page in a week if no major 
objections come up.


Cheers,

Roland

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

Re: [Talk-transit] Naming concepts

[Roland Olbricht]

Hi all,


1. A general public transport service (e.g. No. 38):
In OSM: "route_master" in GTFS: "route"


For me that is a line. It has a line number. (which sometimes is not simply
numeric, so it's more of a symbol, but OK)


2. A theoretical tour a bus takes, but without schedule information, it
represents one each for different direction, but also if one is shorter
than the other
In OSM: "route"; in GTFS: /not existent/


I would call those itinerary. If OSM had started out with that term, we
wouldn't have the ambiguity today. But route is used for foot/bicycle/horse
and PT itineraries. For PT I resorted to call them route variations, but
they are 'represented' by route relations in OSM.


3. An actual tour a bus takes, on a certain time
In OSM" not existen; in GTFS: "trip"


[..] If we could figure out a way to represent it anyway, I think it
would be a plus. But I won't be holding my breath.


I fully support that wording.

But I would like to point you to another problem that has kept and is keeping 
OSM PT painful:
There are two very distinct underlying data models in use by the transit 
agencies.

The metropolitan (line based) model looks like subway lines usually look:
The full schedule is essentially modeled by the itineraries plus the list of 
departure times per itinerary.
This works because all trips have the same set of stops and approximately the 
same travel time.
If there are many trips per itinerary then there might not even be a fixed list 
of departure times but just a defined departure frequency,
like
  05h48 06h00 then every 2 to 5 Minutes 19h00 19h13 19h28 ...
That is all you need to know. Frequencies depend on the hardware (signalling 
limits, number of vehicles for the line).
Thus they usually persist for years or decades. First and last times depends on 
the habits of the local users and
therefore also persist usually for years. It would make sense to have that 
information in OSM.

The rural model, also often used for long distance service, looks like school 
buses:
Different trips may vary wildly, and times fluctuate quite often. A useful data 
model would have to capture not only an itinerary for each single trip, but 
also the operating dates.
This is out of scope for OSM, because it is ephemeral.
Nonetheless, trips have a line number that is displayed.

Operations based on the metropolitan model tend to be attractive for passengers 
from the general public.
Operations based on the rural model tend to be cheap for the agency.
This is why it is a political issue to tell a local community that their public 
transport network is too rural for OSM.

Long story cut short:
I would suggest that you keep a structure for unassigned trips in your 
intermediate data structure, even if that is not filled from OSM.
If you want to fight for timetable data according to the metropolitan model in 
OSM, then you have my support.
But a lot of people have tried that years ago and each eventually resigned.
There is quite a vocal part of the community concerned with more rural-style 
services, and they have defeated so far all apporaches to metropolitan style 
information to OSM.

Best regards,

Roland

--
Dr. Roland Olbricht
MENTZ GmbH, Am Mittelhafen 10, 48155 Münster
T: +49 (0)251 7 03 30-232, F: +49 (0)251 7 03 30-300
E: olbri...@mentz.net, www.mentz.net

Sitz der Gesellschaft:
Grillparzerstraße 18, 81675 München
Geschäftsführer Dr.-Ing. Hans-J. Mentz
Amtsgericht München, HRB 91898

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

Re: [OSM-talk] Overpass XAPI URL Status

[Roland Olbricht]

Hi Bryce,


I help support a large company that uses OSM data, pulled via a specific
query at  ://www.overpass-api.de/api/xapi
. This query runs about once a month.


thank you for asking back.

First about the status: when I last checked some days ago then there 
have been still almost a million requests for /xapi . This is in 
contrast to 500.000 requests for all other API endpoints combined.
Yesterday figures are 1067494 for /xapi and 937498 for all other API 
call combined.


The bigger surprise came when I have taken a sample of 100 requests from 
xapi calls. I turned out that while they are from various apps still all 
100 of them were less desirable bulk load. At that point I decided to 
wait until somebody comes up with a real request to get the xapi call 
back. This has happened right now.


For that reason I have configured the service now as follows:
- xapi works again
- xapi?map now returns 400 Bad request as I have turned off that in the 
syntax recognition


I think that a longtime solution will be to take the referrer and user 
agent into account when scheduling requests. But this has not been 
implemented yet.


I would like to conclude with some remarks to hedge rumors on this thread:

The OSMF is not in any way involved in operations. Paul's mail describes 
the precise situation. Please note that the whole purpose of third party 
services (like Overpass API) for secondary functionality is to keep that 
burden off the OSMF.


Nothing is held confidentially on purpose. There are two limitations 
that might give this impression:
- I'm on vacation right now and until SotM and relatively unwillig to 
answer questions immediately.

- The log files may contain personal data and thus I won't hand them out

Best regards,

Roland


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

Re: [Talk-de] Konfigurationsfehler Apache www.openstreetmap.de (WAS: Deutsche Homepage - Fehlermeldung)

[Roland Olbricht]

Hi,


es gibt einen ganz neuen Security-Checker von Mozilla.
http://www.heise.de/newsticker/meldung/Mozilla-bringt-kostenlosen-Sicherheitstest-fuer-Websites-3306197.html

An dem beiße ich mir zur Zeit die Zähne aus. Die Details kann ich noch
nicht beurteilen, geschweige denn anpassen.


Das Ding ist grob unseriös. Z.B. ist CORS ein anerkannter Web-Standard, 
der regelt, wie Daten von Drittseiten eingebunden werden können. Folgt 
man dem Standard, dann besteht keinerlei Sicherheitsrisiko. Ohne auch 
nicht unbedingt, aber das ist ein anderes Thema.


Der Security Check streicht aber die Hälfte der Punkte, wenn eine 
Website den Standard unterstützt.


Auch die übrigen Anforderungen sind vom Typ: "sende noch diese 27 
Extra-Header mit". Vom Senden zusätzlicher Header wird allerdings nichts 
sicherer. Entweder hat der Server oder der Client eine Sicherheitslücke 
oder nicht. Entweder gibt es einen Man-In-The-Middle, der dann auch die 
Header setzen oder durchreichen kann, oder nicht.


Das steht im starken Kontrast zu SSLLabs. Dort wird gezielt getestet, ob 
man abgehört werden oder Inhalte untergeschoben bekommen kann, obwohl 
die SSL-Verschlüsselung aktiv ist. Das ergibt Sinn, weil man mit SSL 
(HTTPS) das nicht erwarten würde.


Es lohnt also nicht, für den Mozilla-Scan irgendwas zu tun. Das Ding ist 
Web-Politik, nicht Web-Sicherheit.


Viele Grüße,
Roland


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

[Talk-GB] Overpass API in English

[Roland Olbricht]

Dear mappers,

I would like to ask those of you that are keen of proper British English 
to help with the wording of Overpass API.


As SomeoneElse pointed out in
https://github.com/drolbr/Overpass-API/issues/291
there are messages from Overpass API that are poor language.
DaveF has pointed out before that the word "attic" may be difficult to 
understand.


Thus I 've set up a page of all messages that Overpass API can emit:
http://wiki.openstreetmap.org/wiki/Overpass_API/Wording
And I would like to ask you to add suggestions for better wording or 
discussions direct on that wiki page. If I understand the point of the 
suggestion and doesn't produce homonyms or conflicts with the language 
of referred web standards then I will built them into Overpass API as 
soon as possible.


Best regards,

Roland

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

Re: [Talk-transit] GTFS, tools and pt tags generally

[Roland Olbricht]

I'm sorry if I was unclear.  I didn't mean that one person should just
blindly dump every GTFS feed into OSM and leave it to others to clean
up.  I was thinking of something that an individual mapper could use to
import the feed(s) in their particular area and resolve conflicts or
errors before uploading, e.g. in JOSM.


Thank you for the clarification. Yes, I would agree to that. I could 
image to let a JOSM plugin produce a layer of coordinates from the GTFS 
stop data.


There could as well be a feature to do routing along the sequence of 
stops that are provided with GTFS data.



Perhaps it's different in Rightpondia, but here in Leftpondia, it's
common to see major (sometimes network-wide) changes to routes and
schedules every 3-6 months.


Thank you. This is indeed an important disctinction. Here, bus services 
are stable always at least a year, usually five to ten years and 
sometimes for decades. Services on rails are usually even more stable.


For example, my ancient home town Wuppertal introduced a new bus network 
in 1994 and is mostly offering the same service right now.


Best regards,

Roland


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

Re: [Talk-transit] GTFS, tools and pt tags generally

[Roland Olbricht]

Hi,


OTOH, this doesn't seem like a huge problem if we're importing the data
from elsewhere using automated tools and only tweaking by hand where
it's wrong--and ideally, there should be some sort of feedback mechanism
to get the source corrected so even that's a short-term problem.


Well, that's explicitly deprecated in OSM. Please look in the wiki about 
mechanical edits.


If you have useful and free data then the better approach is to mix them 
up with OSM data outside OSM and give the OSM mappers a tool such that 
each mapper can pick what he/she deems useful in OSM.



Also, like it or not, Google Maps (and hence GTFS) has set a bar for
what users expect from online maps.  I'd certainly like OSM to be
better, of course, but the current situation is that OSM is generally
far, far worse.


I think this is where local differences matter. In large parts of 
Europe, the transit agencies themselves have already good information, 
OSM is more or less on par with that, and Google lags significantly behind.



And: how to tell apart services that run a few times per day from those
that have a headway of a few minutes?


That's starting down a slippery slope to including full schedule data.


Once again, please note that this is a huge difference in local culture.

All around the world, if there is a metro then people usually go there 
without looking on a timetable and it as granted that the headway is a 
few minutes. Next to nobody consults a timetable first, and some systems 
don't even public precise timetables.


Believe it or not, there are quite a number of bus service mimicking 
this concept:

https://fr.wikipedia.org/wiki/Bus_%C3%A0_haut_niveau_de_service

This is in contrast to a number of service that run once a day on 
schooldays.


In between, there are a lot of services that have a fixed headway all 
over the day:

https://fr.wikipedia.org/wiki/Horaire_cadenc%C3%A9

In practice here in Europe, reducing complexity would mean to send a 
potential passenger to the next stop of a high frenquency service or 
clock-face scheduled service and to ignore once-a-day services altogether.


And the right solution for this is not to delete these services from OSM 
but to mark them as low-frequency service.


If you would like to improve relevance of OSM, discriminating between 
these three levels of service would be a prime concern.



- Where to start/end routing of vehicles?


Sorry for the misunderstanding. I'm talking about getting a vehicle from 
stop to stop. While the overall level of detail is often good enough for 
routing, this doesn't hold always. To find and resolve the mapping 
issues it makes sense to check whether you can route from stop to stop. 
If not, this is always a strong hint that there are mapping issues.


I do notice as a benefit from this discussion that not all transit 
agencies (Tulsa, Portland) care whether their routes can be lawfully 
driven in reality. That's different here in, at least in Western Europe, 
maybe all Europe.



- How to obtain a name of a station?


Please start trying to work with the data.

Names can come from the pole, the platform, the stop_position, a 
connecting stop area. Or a combination of that, including contradicting 
information. Factor in "local_name", "loc_name", "official_name", 
probably others, and in countries like Switzerland and Belgium names in 
multiple languages.


To make things more fun, some stations have different names for some of 
their stops within the station. And add abbreviations to the equation or 
the repetition of the municipality name in the name tag.


I would like to see a set of rules that answer questions like:
- Does a "name:en" tag on the pole override a "name" tag on the 
stop_position, or vice versa? What about a "name:en" tag on a 
stop_position versus "name" on a platform?
- Should "Hbf" be expanded to "Hauptbahnhof", or the suffix "(Westf)" to 
"(Westfalen)"?
- Have the tracks in the station "Vaugirard" this name or the name 
"Montparnasse"?


Paul has already mentioned that, to the contrary of these observations, 
at some places the stops don't have explicit names and get their names 
from nearby street features.


To sum up: if you set up a consolidation service to mix up GTFS data 
with OSM data outside OSM, a lot of people would be grateful. If you 
push somehow converted GTFS data into OSM then most mapppers will treat 
this as more harm than good.


Best regards,

Roland


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

[Talk-GB] Remove tag "priority" from railways

[Roland Olbricht]

Dear all,

we (corporation Mentz) would like to remove the tag "priority" from the 
railways in GB.

They have been intially set by us to denote railway lines with important 
passenger traffic. But the German community has asked us there to use the route 
relations for that purpose instead. That has the advantage that the burden of 
maintaining it up to date is shared by more eyeballs.

We would like to keep this consistent in GB. It is only one line affected:
http://overpass-turbo.eu/s/fNB

I would therefore suggest to do a mechanical edit that drops the tag "prioity" 
from the ways of this line.

Best regards,

Roland

--
Dr. Roland Olbricht
mdv - Mentz Datenverarbeitung GmbH
Am Mittelhafen 10
48155 Münster
e-Mail: olbri...@mentz.net
Tel: +49 (0) 251 70330 232
Fax: +49 (0) 251 70330 300
http://www.mentz.net

Sitz der Gesellschaft:
Grillparzerstraße 18, 81675 München
Geschäftsführer Dr.-Ing. Hans-J. Mentz
Amtsgericht München, HRB 91898

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

[Talk-de] Eisenbahn-Themen auf osm-nahverkehr

[Roland Olbricht]

Hallo zusammen,

bevor jemand sich übergangen fühlt, ein Mechanischer Edit ("priority" 
von Ways mit "railway" entfernen) und eine Fragestellung zu einem 
Eisenbahn-Tag ("service"="siding" an wichtigen Bahnhofsgleisen) habe ich 
auf der Liste

http://lists.openstreetmap.de/mailman/listinfo/nahverkehr
aufgeworfen.

Zur Entlastung der Liste talk-de schlage ich vor, Diskussionen dort zu 
führen.


Viele Grüße,

Roland

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

[OSM-talk] RfD notification: Purge tag "priority" from tracks

[Roland Olbricht]

Dear fellow mappers,

we, the company Mentz, would like to fulfill a wish of the German community and 
change our former tagging of railway tracks.

This constitutes a mechanical edit. Therefore, I would like to notify you that 
I have put a request for discussion on talk-transit@ .
If you would like to discuss, please do so there.

Best regards,

Roland

--
Dr. Roland Olbricht
mdv - Mentz Datenverarbeitung GmbH
Am Mittelhafen 10
48155 Münster
e-Mail: olbri...@mentz.net
Tel: +49 (0) 251 70330 232
Fax: +49 (0) 251 70330 300
http://www.mentz.net

Sitz der Gesellschaft:
Grillparzerstraße 18, 81675 München
Geschäftsführer Dr.-Ing. Hans-J. Mentz
Amtsgericht München, HRB 91898

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

Re: [Talk-de] Solingen

[Roland Olbricht]

Hallo Simon,


Ich habe einen Kontakt. via legal-questi...@osmfoundation.org, mit
jemand von "Vermessung und Kataster" der Stadt Solingen, der uns
anscheinend diverse Strassen(um)benennungen mitteilen will.


Der nächstgelegene tatsächlich aktive Stammtisch ist Düsseldorf. In der 
Umgebung, in Wuppertal, sehr aktiv und ansprechbar ist User 
bilderhobbit. Von der Ortskenntnis her kannst Du mich aber auch gerne in 
CC nehmen.


Viele Grüße,

Roland


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