Re: [OSM-talk] replace some obviously mistaken surface values by their clear intended meaning

[Tobias Knerr]

On 11.02.23 18:41 Mateusz Konieczny wrote:

I propose to replace following surface tags by doing an automated edit


I wholeheartedly support this proposal, thank you for your work!

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

Re: [OSM-talk] FYI: Board now requires imports list (in)compatibility with OSM CT (& will work on a template)

[Tobias Knerr]

On 29.11.22 16:38 Dave F wrote:
If it's a licence change by OSM then how can a maintainer of a database 
possibly account for a future, unspecified change who's implementation 
was out of their control?


Yes, it's about a license change by OSM.

I don't think it's outlandish to assume that at least some data donors 
are comfortable with such terms. After all, this is something that we 
expect of individual contributors: The Contributor Terms which every 
person with an OSM account has signed grants us (meaning the OSMF board 
and a 2/3 majority of active contributors) the right to switch to any 
unspecified open license in the future.


Could you expand on what you mean by 'legal text'. Is it a legally 
binding contract?


Answering by way of example: I would expect a similar implementation to 
the standard waiver we ask for before we import CC-BY data:

https://drive.google.com/file/d/0B3PN5zfbzThqeTdWR1l3SzJVcTg/view?resourcekey=0-PzVtHArfxvbYidpW2-AVTg

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

Re: [OSM-talk] FYI: Board now requires imports list (in)compatibility with OSM CT (& will work on a template)

[Tobias Knerr]

On 29.11.22 08:14 Simon Poole wrote:
The main question is what "expect it to survive a hypothetical license 
change" implies. My expectation is that because of practical 
considerations any future licence would require downstream attribution 
of OSM so that the OSMF can continue to offer third party sources 
indirect attribution.


You have a point that it seems practical to look just at the more narrow 
scenario of another license that requires attribution of OSM. After all, 
a license change is not a high-probability event in the first place, and 
a change to a license that doesn't require some form of attribution 
seems even more unlikely. So it would be useful to be able to record 
something like "as long as attribution is ensured" for an import's 
license change compatibility.


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

Re: [OSM-talk] FYI: Board now requires imports list (in)compatibility with OSM CT (& will work on a template)

[Tobias Knerr]

On 29.11.22 03:57 Minh Nguyen wrote:
Could you clarify the "perhaps" here? If something has been explicitly 
dedicated to the public domain via CC0, a similar statement, or a 
relevant law, should it not survive any relicensing attempt? Or is this 
just about the editorial decision of whether to leave the table cell 
blank if relicensing is irrelevant for a given import?


This is about dealing with some issues of importing share-alike 
datasets. There is no intention to change the way we interact with 
public domain datasets which already leave us ample flexibility for 
importing and redistributing them.


The "perhaps" was indeed just alluding to an editorial decision 
regarding the wiki table. Sorry for the confusion.




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

Re: [OSM-talk] FYI: Board now requires imports list (in)compatibility with OSM CT (& will work on a template)

[Tobias Knerr]

On 28.11.22 at Simon Poole wrote:

What is "OSM Contributor Terms compatibility" supposed to be?


Ok, this is clearly imprecise wording.¹

The context is that we would like to offer data donors a standard legal 
text that they can use to make their data available to OSM in such a way 
that we would expect it to survive a hypothetical license change. And 
yes, this would perhaps look similar to a CC0 waiver, except that it 
could potentially be a bit more limited (in a similar way the CT limits 
the set of licenses under which the OSMF can choose to publish the 
database).


So the column would be mostly about whether this legal text or something 
equivalent has been signed or not (+ perhaps public domain/CC0 data that 
has the ability to survive a license change by default could also check 
the box).


Tobias

¹ The wording is my fault and, iirc, was inspired by the column name at 
https://wiki.osm.org/Import/ODbL_Compatibility



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

Re: [OSM-talk] RFC: Two new extensions for the wiki: Log in via openstreetmap.org and vote via a GUI

[Tobias Knerr]

On 13.10.22 11:47 Martin Fischer wrote:
I wrote two small MediaWiki extensions for wiki.openstreetmap.org: one 
to let you log in via your OSM account and one to provide an easy to use 
in-wiki GUI for proposal voting.


Awesome work, I like both of these and hope they make it onto the OSM 
wiki! :)


Of course, this gets me thinking again about unifying OSM and wiki 
accounts and how we could get closer to that goal by disabling "regular" 
account creation on the wiki after your extension is installed. But I 
like that installing it immediately offers tangible benefits regardless 
of any such extra steps.


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

[Talk-de] Kandidatur für den OSMF-Vorstand

[Tobias Knerr]

Hallo zusammen,

morgen beginnen die diesjährigen Vorstandswahlen¹ der OSM Foundation,
und wie einige von euch schon wissen, habe mich entschieden, noch einmal
anzutreten.

Ich bin ja jetzt seit zwei Jahren Vorstandsmitglied. Nicht alle Ideen,
die ich bei meiner letzten Wahl hatte, waren im Vorstand mehrheitsfähig,
aber einiges konnte ich doch umsetzen – etwa die Mehrheit der Punkte,
die ich in meinem damaligen Wahlprogramm² aufgeführt hatte.

Nichtsdestotrotz ist das eigentlich eine Daueraufgabe. Manche Probleme
sind wir angegangen, dafür kommen neue Herausforderungen auf uns zu, z.B.:

* Die zunehmende Firmenpräsenz in den Working Groups der OSMF.
* Die Risiken, wenn Arbeit in der Foundation zunehmend durch bezahlte
Kräfte erledigt wird.
* Der wachsende Anteil bezahlten und organisierten Mappings an den
Beiträgen zu OSM, und die Nutzung von Werkzeugen wie RapiD.
* Die immer noch unzureichende Durchsetzung unserer Standards für
Namensnennung, gerade bei prominenten Datennutzern wie Facebook.

Dafür zu sorgen, dass die Interessen der freiwilligen Mapper bei den
Veränderungen in OSM nicht unter die Räder kommen, wird also weiter ein
Schwerpunkt für mich sein. Allerdings will ich mich nicht darauf
beschränken. Mir liegt auch am Herzen, den Innovationsstau bei der
zentralen Infrastruktur von OSM zu lösen: Dass etwa die API seit über
einem Jahrzehnt keine großen Updates mehr erlebt hat, die OSM-Hauptseite
nur einen Bruchteil der Möglichkeiten von OSM zeigt, die Leute von Forum
und Mailingliste in proprietäre soziale Netzwerke abwandern oder dass
wir lange gewünschten Website-Features in den letzten Jahren kaum einen
Schritt näher gekommen sind. Da die OSMF diese Dienste betreibt, sollten
wir auch dafür sorgen, dass sie mit dem Rest des OSM-Universums Schritt
halten.

Die offizielle Sammlung³ der Antworten und Positionen aller Kandidaten
wurde inzwischen veröffentlicht, meine findet ihr hier:
https://wiki.openstreetmap.org/wiki/Foundation/AGM20/Election_to_Board/Answers_and_manifestos/Tobias_Knerr

Dort äußere ich mich sehr viel ausführlicher (auf Englisch, aber es
überlebt eine automatische Übersetzung einigermaßen heil :)). Ich stehe
euch aber auch hier auf der Liste gern Rede und Antwort!

Viele Grüße,
Tobias


PS: Ich möchte euch bei dieser Gelegenheit die zusammen mit den Wahlen
stattfindenden Abstimmungen über eine Ausweitung der Beitragsbefreiung
für aktive Mapper auf die normale Mitgliedschaft sowie die beiden
Vorschläge zum Schutz vor Übernahmeversuchen (Mindestvoraussetzungen für
die Mitgliedschaft, Verbot von durch den Arbeitgeber gesteuerter
Stimmabgabe) ans Herz legen. Die letzten beiden sind zwar noch keine
konkreten Änderungen, sondern nur eine Aufforderung an den Vorstand,
entsprechende Vorschläge zu erarbeiten, aber ein klares Ergebnis würde
dennoch ein wichtiges Signal senden.


¹ https://wiki.openstreetmap.org/wiki/Foundation/AGM20/Election_to_Board
²
https://wiki.openstreetmap.org/wiki/User:De:Tordanik/2018_OSMF_board_elections_manifesto
³
https://wiki.openstreetmap.org/wiki/Foundation/AGM20/Election_to_Board/Answers_and_manifestos

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

Re: [OSM-talk] reddit AMA with some OSMF Board members. 15:00Z 9 Nov

[Tobias Knerr]

On 30.10.20 10:04, Martin Koppenhoefer wrote:
> Rory, I am absolutely sure there was no bad intent in the choice of
> format and platform, but given where this discussion went so fast, I
> believe the setting should be reconsidered, evaluating the possibility
> of choosing an open platform.

When I asked him, Spanholz said he would be happy to see the questions
and answers mirrored onto an open platform. All it takes is one
volunteer (or several) to step forward and do the manual work of copying
content back and forth.

Which open platform? Up to whoever volunteers. :)

And of course, the offer to submit questions by direct message still stands:

On 29.10.20 22:58, Tobias Knerr wrote:
> * Spanholz, the user who has been most active in organizing this AMA,
> has already offered to post questions on behalf of other people. So
> you can send in your questions without needing to sign up to reddit.

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

Re: [OSM-talk] reddit AMA with some OSMF Board members. 15:00Z 9 Nov

[Tobias Knerr]

I've been considering the downsides of using a proprietary channel when
I was invited to participate. My thinking is:

* The questions and answers are publicly visible. (Yes, Reddit may nag
you sign up or install their app – close that noise.)
* Spanholz, the user who has been most active in organizing this AMA,
has already offered to post questions on behalf of other people. So you
can send in your questions without needing to sign up to reddit.

For something that's not an official event (just something individual
board members participate in), these options seem good enough.

Is it ideal? No, and I would be more than happy to participate in an
event hosted on our open platforms. But it's an initiative that I want
to encourage, as I hope it could get more OSM community members
interested in foundation matters, and the foundation could use more
active participation. It would be even better if community members took
the initiative to run more fun events on our self-hosted platforms –
that would probably do more to make them more lively and active than the
board could ever hope to achieve with its decrees.

(And of course you can ask questions on OSM channels around the year, no
need to wait for an "AMA". I know I don't need to tell that to you in
particular, but I wish the bulk of the community was less shy about
speaking up on OSMF issues.)

On 29.10.20 21:30, Christoph Hormann wrote:
> So i suppose you will circumnavigate any subject related to OSMF governance 
> or the election and that you will not refer to what is going to be said there 
> in any future discussion of OSMF matters (because then it would need to be 
> considered as part of a consultation by the board).

Not every communication between a member of the board and one or more
community member(s) constitutes a "consultation". It's good to be wary
about slippery slopes, but this just doesn't make the cut.

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

Re: [OSM-talk] M$ Flightsimulator

[Tobias Knerr]

On 31.08.20 15:48, Martin Koppenhoefer wrote:
> https://www.rockpapershotgun.com/2020/08/28/players-are-fixing-microsoft-flight-simulators-missing-monuments-with-google-maps/
> 
> is there a way to import this data back to OpenStreetMap?

Given that they're using Google Maps, I doubt it.

But I do feel there is some potential for a free collection of
crowdsourced 3D models for use with OSM (beyond what's possible with
Simple 3D Buildings). This is the gap I hoped the 3D Model Repository
(https://3dmr.eu/) would fill, but so far it hasn't taken off.

If someone is interested in helping with that, there's a lot to do.
Creating models, helping with coding (gltf support would be nice, for
example), and there's even data we're permitted to import into 3DMR that
hasn't been uploaded simply due to lack of time for converting/cleaning
up the models.

Yours,
Tobias

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

Re: [OSM-talk] Removing all signposts from relations

[Tobias Knerr]

On 25.07.20 18:14, pangoSE wrote:
> Recently it was discussed whether to have signposts in route relations.
> I suggest we delete them from all relations by running a script.
> I se no loss of information

It loses the information whether or not a route is signed at a
particular signpost. Because, no, it is not the case that every signpost
will always contain directions for every route running closer than x
meters past it.

You may not personally care about that information, but that's a very
different argument. These are verifiable facts that someone found useful
enough to spend time mapping, and I don't think there's anything
inherently wrong with having them in OSM.

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

Re: [OSM-talk] Could/should editors detect/disallow huge changeset bboxes?

[Tobias Knerr]

On 12.06.20 13:00, Frederik Ramm wrote:
> I wonder if it would be feasible or desirable for editors to warn users
> if they are at risk of creating country/world-spanning changesets.

It would certainly be a improvement for day-to-day work.

The root of the issue, though, is that bounding boxes are a poor basis
to determine whether a changeset is of interest to a mapper watching a
particular region. If a changeset contains a change in France and one in
Poland, then a mapper observing Germany should really just not be
alerted to that changeset in the first place, and it should be possible
for a mapper in Poland to view only the subset of the changes that
affect their own country.

IMO, an ideal changeset represents one logical unit of work. It
shouldn't contain multiple unrelated changes, but at the same time,
related changes should not be split across different changesets. Right
now we're intentionally doing the latter to work around the limitations
in our tools, and I understand and support that, but I hope this view of
"large bbox = bad" doesn't get too firmly entrenched. Let's keep in mind
that it's essentially a workaround for missing software features, that
the proper fix is to improve the software, and that we should drop this
rule once the reasons for it no longer exist.

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

Re: [Talk-de] Massenweise Entfernung von oneway=no

[Tobias Knerr]

On 22.05.20 15:15, Volker Schmidt wrote:
> Ich persoenlich setze routinemaessig oneway=no um anzuzeigen, dass ich
> geprueft habe, dass die Strasse keine Einbahnstrasse ist. In Verbindung mit
> dem Aenderungsdatum ist das nuetzlich in Gegenden, wo Strassenrichtungen
> haeufig von den Behoerden geaendert werden.

Meiner Meinung nach geht die Idee, Default-Werte explizit zu setzen, zu
Lasten der Übersichtlichkeit. Die logische Konsequenz wären ja
maxweight=none, maxheight=none, bridge=no, tunnel=no, covered=no
access=yes vehicle=yes motor_vehicle=yes etc. an fast jeder Straße. Und
wie mappe ich z.B., dass zwischen zwei Straßen keine Abbiegebeschränkung
besteht – lege ich dann jeweils eine Relation mit restriction=allowed
an? Wie mappe ich, dass an einer Stelle kein Gebäude steht, in einem
Gebäude kein weiterer Laden mehr ist, auf dem Gehsteig kein weiterer
Abfalleimer steht, ...?

Vielleicht etwas übertrieben, aber worauf ich hinaus will: Die
Abwesenheit von einem Objekt oder Attribut sollte normalerweise nicht
erfasst werden – nur in Ausnahmefällen dort, wo sie überraschend ist
(weil es kürzlich anders war, die Luftbilder veraltet sind, es bei den
Straßen drumherum anders ist, ...) . Wenn in deiner Gegend bestimmte
Arten von Straßen oft "umgedreht" werden, kann das durchaus so ein Fall
sein.

Aber auch dann wäre evtl. etwas nach Art von last_check:oneway=
besser, denn das funktioniert öfter als nur bei der ersten Überprüfung
und es beeinträchtigt als klar erkennbares Qualitätssicherungs-Tag die
Übersicht weniger.

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

Re: [OSM-talk] Bridge area construction

[Tobias Knerr]

On 05.05.20 22:24, Jack Armstrong wrote:
> man_made=construction
> construction=bridge
> layer=1

The =construction + construction= tagging is only really
common for highway, building and railway tags (where it sticks around
for historic reasons, in my impression).

Other tags are more likely to use to use lifecycle prefixes:
https://wiki.openstreetmap.org/wiki/Lifecycle_prefix

For your example, that would be:

construction:man_made = bridge
layer = 1

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

Re: [OSM-talk] Let's talk Attribution

[Tobias Knerr]

Hi Alexandre,

it's true that too many projects using OSM do not provide the required
attribution. However, I'm surprised that you got reactions of
"this is fine" for some of the more egregious examples you mention in
your email. While individual mappers will of course hold a wide range of
opinions, that is not the position of the OSM Foundation.

On 27.04.20 19:49, Alexandre Oliveira wrote:
> On the mobile
> version of the Facebook page, there's no attribution at all, simply a
> map. And worse, it redirects to Google Maps when you click on it.

I assume this is the same issue as the one described here:
https://github.com/grischard/osm-lacking-attribution/issues/8

Facebook was contacted about this specific problem 2.5 months ago. They
have acknowledged it as an issue, but have unfortunately failed to
correct it so far. For now, we still have hope that they will just
finally fix it. At some point, we may have to take further steps, but we
haven't really come to an agreement on what those would be.

For OSMF action on issues which are less clear-cut (i.e. attribution is
present, but insufficient), the main roadblock is that we have not yet
approved the attribution guidelines which will make it clearer what
style of attribution we expect. Of course, data users are already
obligated to follow our license today, but hopefully the guidelines will
help to eliminate any ambiguity about whether certain controversial
practices are acceptable. The most recent version of the guidelines
drafted by the LWG is almost there, but has drawn community criticism
about being too generous especially w.r.t. initially hidden attribution.
We are working on them, and once they are approved, we will point to
them when we contact data users about low-quality attribution.

I admit that the OSMF has been frustratingly slow to make progress on
attribution, and I hope we will get better about this.
But there's a lot that can be achieved by the community in a distributed
manner as well. You've already mentioned the #AttributionIsNotOptional
initiative as an example. It's not rare to hear success stories about
mappers simply sending a friendly reminder to some companies, especially
small-scale users who made a honest mistake and forgot about the
attribution. It also helps to report lacking attribution to Guillaume's
previously mentioned issue tracker¹ – the board is keeping an eye on
that and prioritizing issues based on whether the site or app has
already been contacted, how bad the attribution is, and on how visible
the site is.

In any case, I'd like to emphasize that a slow response to missing
attribution should not be mistaken for being ok with it. Nor does it
mean that we will not act more decisively in the future. Visible
attribution is a key requirement of our license, and not optional.

Tobias

 ¹ https://github.com/grischard/osm-lacking-attribution

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

[Talk-de] Dienste für virtuelle OSM-Stammtische

[Tobias Knerr]

Viele OSM-Stammtische finden derzeit wegen der Corona-Pandemie nicht
statt. Es gibt aber Alternativen! Einige Gruppen haben schon erste
virtuelle Treffen erfolgreich durchgeführt.

Wer noch auf der Suche nach geeigneten Diensten dafür ist, findet hier
ein paar von uns getestete Vorschläge:

* BigBlueButton: Der OSMF-Vorstand benutzt seit April eine gemietete
Instanz der freien Videochat-Software BigBlueButton für
Vorstandstreffen. Diese steht auch der OSM-Community zur Verfügung. Um
sie zu nutzen, muss einer der Teilnehmer des Treffens sich unter
https://osmvideo.cloud68.co/user/signup registrieren. Nach der Anmeldung
findet man dann einen Link zu seinem eigenen "Home Room", den man mit
anderen Nutzern teilen kann.

http://imagico.de/files/bbb1.png

* Jitsi: Die derzeit wohl bekannteste freie Lösung für Videochats. Es
gibt eine ganze Reihe frei nutzbarer Jitsi-Server im Netz, eine Liste
findet sich unter https://pads.ccc.de/ep/pad/view/jitsiliste/latest.  Um
ein Jitsi-Treffen zu starten, wählt man dafür einen eindeutigen Namen
und teilt diesen mit allen Teilnehmern.

http://imagico.de/files/jitsi1.png

* Mumble: Wer auf das Video-Bild verzichten kann oder möchte findet mit
Mumble eine deutlich schmalbandigere Lösung, die aber im Gegensatz zu
den übrigen Möglichkeiten die Installation einer eigenen Software
erfordert.  Wer schon mal bei einem FOSSGIS- oder OSMF-Vorstandstreffen
zugehört hat, kennt dies bereits.  Eine Anleitung findet sich unter
http://podcast.openstreetmap.de/mitmachen/.  Der FOSSGIS-Mumble-Server
kann von allen in der OSM-Community verwendet werden, daneben gibt es
als Ausweich-Möglichkeit auch noch einen Mumble-Server von HOT:
https://wiki.osm.org/Mumble

Egal für welche technische Lösung ihr euch entscheidet - am Anfang mag
dies erst einmal ungewohnt erscheinen.  Aber ausprobieren lohnt sich!
Viele, die jetzt in Zeiten der Corona-Pandemie zum ersten Mal virtuelle
Treffen ausprobiert haben sind positiv überrascht, wie kommunikativ so
was sein kann.  Also: keine Scheu beim ausprobieren und teilt Eure
Erfahrungen in der OSM-Community.

(Danke an Christoph für die Hilfe beim Testen und Texten!)

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

Re: [OSM-talk] remove the suggestion to credit "contributors"

[Tobias Knerr]

On 17.04.20 15:33, Mario Frasca wrote:
> On 17/04/2020 04:20, Martin Koppenhoefer wrote:
>> What about removing [the trailing "contributors" from the ©
>> attribution], so that the required credit becomes "© OpenStreetMap"
>> (it could also be © OpenStreetMapFoundation, but maybe "©
>> OpenStreetMap" would be sufficient, given that OpenStreetMap is a
>> brand owned by the OpenStreetMapFoundation)?
> 
> I find the explanatory text in parentheses confusing.

Agreed, the text in parentheses is problematic. From a moral
perspective, explicitly crediting the foundation would very much feel
like an unjust appropriation of the mappers' work, regardless of the
legal technicality that the OSMF is publishing the database.

> I'm fine with associating OSM with its contributors, so if you say that
> "© OpenStreetMap" is the same as "© OpenStreetMap contributors", I'm fine.

+1. To me, the foundation is not OpenStreetMap. It's an entity that
exists to *support* OpenStreetMap. (It's good that the OSMF makes this
mental distinction visible by using separate domain, osmfoundation.org.)
When I think of OpenStreetMap, I think of the many people who help build
our map, not a formal incorporated entity. I hope that other mappers
also see themselves as part of OpenStreetMap. So as I said before, I
like the core of the suggestion – but it could have been presented
better by leaving the foundation bit out of it.

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

Re: [OSM-legal-talk] [OSM-talk] remove the suggestion to credit "contributors"

[Tobias Knerr]

On 17.04.20 11:20, Martin Koppenhoefer wrote:
> What about removing this, so that the required credit becomes "©
> OpenStreetMap"

Yes, crediting © OpenStreetMap with the appropriate link would be a good
solution. Aside from being more concise, it's a lot less awkward in a
non-English or multilingual context.

Note that our Legal FAQ¹ already allow this in some circumstances:

> Because OpenStreetMap *is* its contributors, you may omit the word
> "contributors" if space is limited.

So using the snappier attribution in all contexts would also simplify
things compared to the status quo of having two different attribution
wordings depending on the available space.

You're in luck, by the way: The latest draft attribution guideline
already proposes this very change. And while there are some problematic
aspects of that draft which need to be changed before it can be
accepted, your suggestion was popular in past discussions (e.g. in
August²), so there's a good chance it will become reality.

Tobias

¹
https://wiki.osm.org/Legal_FAQ#3a._I_would_like_to_use_OpenStreetMap_maps._How_should_I_credit_you.3F
² https://lists.openstreetmap.org/pipermail/talk/2019-August/083078.html

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

Re: [OSM-talk] remove the suggestion to credit "contributors"

[Tobias Knerr]

On 17.04.20 11:20, Martin Koppenhoefer wrote:
> What about removing this, so that the required credit becomes "©
> OpenStreetMap"

Yes, crediting © OpenStreetMap with the appropriate link would be a good
solution. Aside from being more concise, it's a lot less awkward in a
non-English or multilingual context.

Note that our Legal FAQ¹ already allow this in some circumstances:

> Because OpenStreetMap *is* its contributors, you may omit the word
> "contributors" if space is limited.

So using the snappier attribution in all contexts would also simplify
things compared to the status quo of having two different attribution
wordings depending on the available space.

You're in luck, by the way: The latest draft attribution guideline
already proposes this very change. And while there are some problematic
aspects of that draft which need to be changed before it can be
accepted, your suggestion was popular in past discussions (e.g. in
August²), so there's a good chance it will become reality.

Tobias

¹
https://wiki.osm.org/Legal_FAQ#3a._I_would_like_to_use_OpenStreetMap_maps._How_should_I_credit_you.3F
² https://lists.openstreetmap.org/pipermail/talk/2019-August/083078.html

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

Re: [OSM-talk] SotM 2020 - Move to virtual conference

[Tobias Knerr]

On 26.03.20 14:45, Christine Karch wrote:
> the deadline ended a month ago. At the moment it is not planned to call
> for additional submissions.

SotM usually offers numerous slots for Lightning Talks. Will that be the
case with this virtual conference as well? Spontaneous LT submissions
might be an opportunity for people who originally didn't submit because
of the barrier of physical travel.

Also, thanks to everyone in the SotM team for their work under these
unusual circumstances!

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

Re: [OSM-talk] OSM is not the place for dissemination of authoritative data sets

[Tobias Knerr]

On 19.03.20 17:54, Jóhannes Birgir Jensson wrote:
> So - why are authoritative data sets an unwelcome addition?

At its core, OSM is a platform for collaboratively editing geodata. So
the following would be strong reasons not to import a dataset:

- other mappers should not edit it (because the dataset is the official
source and changing it would just make it wrong)
- other mappers cannot meaningfully edit it (because we cannot see the
object in the real world and don't have access to useful sources).

The way you describe it, collaborative editing doesn't seem to be a net
benefit to your scenario, and in fact makes it harder to sync updates
with the authoritative source.

So as a thought experiment: Why not just convert your dataset to the OSM
format to make it compatible with the OSM ecosystem, but skip the import
into the main OSM database?

In practice, I guess part of the answer for that is discoverability: Who
wants to hunt down datasets scattered across various servers and
portals? So it's tempting to put it all into a single big database. And
I guess that's ok as long as it doesn't get in the way of the main
purpose of that database too much – which is collaborative editing, not
data distribution. But surely, with a decent implementation of
compatible data layers tracked in some central repository, authoritative
data could be used *with* OSM without being *in* OSM.

Tobias

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

Re: [OSM-talk] 3D OSM with terrain

[Tobias Knerr]

Hi Nick,

On 06.03.20 18:13, Nick Whitelegg wrote:
> Anyway, I was wondering if there was any active development on
> open-source 3D OSM renderers with terrain?

among the open source options, at least the Blender plugin blender-osm²
and the OSM2World renderer have terrain support.

As maintainer of the latter, I feel I should point out the current
limitations, though: While OSM2World has support for terrain based on
SRTM, that feature is still very experimental. In particular, there is
no level of detail mechanism for terrain (which makes it not scale well
to wide open terrain in the countryside) and the workflow in the desktop
software is inconvenient (need to download SRTM data manually and update
a config file with the path pointing to the dataset).

Due to these quality and performance issues, the first version of our
still-not-finished WebGL client¹ will most likely not include 3D
terrain. But the goal is to eventually get there, so if you see
potential synergies, please reach out!

Tobias

¹ https://wiki.osm.org/OSM2World/WebGL_client
²
https://wiki.osm.org/Blender#blender-osm:_OpenStreetMap_and_Terrain_for_Blender

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

Re: [OSM-talk] Microgrants call for committee

[Tobias Knerr]

Hi all,

reminder that the call for microgrants committee members is about to
close soon. We would still welcome additional applications!

On 16.02.20 12:06, Joost Schouppe wrote:
> Send your application to join the Microgrants Committee to
> microgra...@osmfoundation.org by March 8th.

If you need a quick refresher, the blog post is a good starting point:
https://blog.osm.org/2020/02/17/call-for-microgrants-committee/

Tobias

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

Re: [Talk-de] Datenqualität open data NRW und OSM

[Tobias Knerr]

On 06.03.20 12:42, Florian Lohoff wrote:
> On Fri, Mar 06, 2020 at 11:30:53AM +0100, Otto Dassau wrote:
>> * Könnten/Dürften die Daten NRW genutzt werden, um die OSM Daten
>>   flächendeckend z.B. für NRW zu optimieren? 
> 
> Am Ende nein. Gucken darfst du, aber übernehmen nicht.

Vor ein paar Tagen wurde im Forum die Neuigkeit verbreitet, dass die
"Geobasisdaten NRW" jetzt unter der Datenlizenz Deutschland Zero stehen,
die meines Wissens mit OSM kompatibel ist:
https://forum.openstreetmap.org/viewtopic.php?pid=779174#p779174

Ich bin mir jetzt nicht sicher, ob da die hier diskutierten Daten auch
darunter fallen?

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

Re: [OSM-talk] Regarding GSoC 2020

[Tobias Knerr]

On 26.01.20 14:02, Gollavilli Srikanth wrote:
> [...] I would love to contribute to OpenStreetMap
> in Google Summer of Code 2020.

Thanks for your interest! At the moment, the OSM community is still
preparing for GSoC by collecting project ideas and potential mentors.

So for now, you can keep an eye on our list of project ideas¹ as more
will be added over time. Instructions on how to apply will later be
posted on our wiki as well². Of course, if any of the the existing
project ideas appeal to you, you can already get started by reaching out
to the people listed as points of contact for that idea.

Note that Google hasn't decided on a list of mentoring organizations
yet, so it's not guaranteed that OSM will be involved in GSoC this year.
(But we hope so, of course!)

Yours,
Tobias

¹ https://wiki.osm.org/Google_Summer_of_Code/2019/Project_Ideas
² https://wiki.osm.org/Google_Summer_of_Code/2019



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

Re: [Talk-de] Entfernen des "WikiProject"-Präfixes

[Tobias Knerr]

On 18.08.19 18:44, dcapillae wrote:
> I would like to change the name of the wiki pages related to the Germany
> mapping project to remove the "Wikiproject" prefix according to the
> pages name conventions [1].

Sure, I'd be happy to see the pages renamed. Thanks for all the time you
spend on wiki maintenance!

Für die deutschsprachigen Mitleser: Daniel möchte gern die Seite
"WikiProject Germany" nach "Germany" verschieben, wie er es schon bei
diversen anderen Ländern gemacht hat.

Aus meiner Sicht ist das sinnvoll, da Wikiseiten zu Städten,
Bundesländern etc. schon heute nur den jeweiligen Namen als Seitentitel
haben und die Begrifflichkeit "WikiProject" ein Relikt aus Urzeiten ist,
die heute den durchschnittlichen Leser eher verwirren dürfte.

Bestehende Links werden weiterhin funktionieren, da Weiterleitungen
eingerichtet werden. Daniel verspricht, darauf zu achten, dass alles
weiterhin korrekt funktioniert.

> I could make the necessary changes, and also add the "Country" template
> [9] to the Germany project page, although this change is optional.

I probably wouldn't add the "Country" template. It promises more than
the current page can keep. The page is quite stale at this point, so a
visitor isn't going to find "national events, ongoing projects" or
things like that, unfortunately.

Hier geht es darum, ob die Vorlage https://wiki.osm.org/Template:Country
auf der Wikiseite eingebaut werden soll.

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

Re: [OSM-talk] Attribution guideline status update

[Tobias Knerr]

On 09.08.19 16:35, Frederik Ramm wrote:
> I wonder if we could perhaps get rid of the "Contributors" mention
> altogether.

This idea makes a lot of sense. Especially as both the guideline draft
and the current FAQ already allow this "if space is limited":

> Because OpenStreetMap is its contributors, you may omit the word
> "contributors" if space is limited

So aside from making it much less awkward to attribute OSM in
non-English or multilingual contexts, this change would also simplify
the rules a bit and remove one source of ambiguity. I like it!

Tobias



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

Re: [OSM-talk] Attribution guideline status update

[Tobias Knerr]

Thank you for your work! I believe that clearly documenting our
expectations is a very important step towards solving the current
problems surrounding attribution. It will help well-intentioned data
users to avoid accidentally messing up OSM attribution, and it leaves
fewer excuses for the less well-intentioned ones – making it easier for
us to put pressure on them to improve their practices.

I do have a couple of questions/comments about the current draft:

* Can you confirm that the current attribution practices on Wikipedia
and many similar projects would be covered by the "small images" case?

* I believe video games/simulations should be given similar treatment as
fictional movie productions by permitting attribution in the credits as
an alternative to the current options. Not allowing this seems to
contradict the larger "in a location where customarily attribution would
be expected" principle, as rolling credits are customary for many gaming
genres. (I'm mostly thinking of traditional PC or console games here,
not so much of mobile apps.)

* What's the guidance on scenarios where software does not ship with OSM
data, and does not display online maps, but e.g. allows downloading map
data for offline use? Would it be acceptable to make the license
information part of the download process, or is it still required that
attribution is visible on-screen during use?

Tobias

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

Re: [OSM-talk] Survey on global and local communities in OpenStreetMap

[Tobias Knerr]

Hi Marc,

On 07.08.19 16:53, marc marc wrote:
> where are the results of the previous survey and the resulting actions 
> available?

there were two surveys run by the OSMF in the past months. One was the
survey in advance of the board's face to face meeting in Brussels. We
summarized these survey results as part of this blog post:

https://blog.openstreetmap.org/2019/06/13/surveying-openstreetmap/

Unfortunately, we cannot share the raw dataset as we failed to ask the
participants for their permission to publish their responses. However,
if you have specific questions about the results, we'll try to answer if
possible!

The most commonly mentioned concerns were discussed immediately at the
boards face-to-face meeting in Brussels, and board members are currently
tasked to work on several of them. There were also some ideas which we
felt were not part of the board's responsibilities, so we decided to
forward these to the appropriate parties.

A second, more recent survey was directed to working groups. This effort
is still ongoing – not all groups have responded so far, and I believe
we haven't evaluated the responses in detail yet.

Yours,
Tobias

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

Re: [OSM-talk] Removing "Wikiproject" prefix from place pages

[Tobias Knerr]

I'm in favour of dropping the "WikiProject" prefix from page titles.
It's been mildly bothering me for a while, but the amount of manual
effort involved has stopped me from doing anything about it so far.

Thanks to Daniel for being willing to tackle this! The Talk:Wiki page
and the Wiki subforum might also be good places to potentially recruit
volunteers for the task.

On 18.07.19 11:04, Harry Wood wrote:
> The idea of getting rid of the "WikiProject" page title prefix. There's
> a bit of discussion of that here
> https://wiki.openstreetmap.org/wiki/Talk:Wiki_organisation#Page_Name_conventions.2Fguidelines

Interesting background, thanks! This kind of history isn't always easy
to find if you're not aware of it.

Tobias

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

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

[Tobias Knerr]

On 04.07.19 05:53, Joseph Eisenberg wrote:
> 2 Verifiability (+Map what's on the ground, Don't map: historic
> events, temporary features, local legislation etc)

In my opinion, the practices that you've turned into subheadings of the
verifiability section are not merely special cases of verifiability.

For example, temporary features are perfectly verifiable (until they
cease to exist, of course). The reasons why it's not usually considered
good practice to map them include the unsustainable maintenance effort
and the impact on offline use of our data.

So I feel these items are really their own separate practices, not part
of verifiability. If you want to avoid having too many top-level
headings, you might still be able to group the three "Don't map..."
rules into a common section.

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

Re: [OSM-talk] Wikibase items instead of usual templates for wiki pages?

[Tobias Knerr]

On 09.06.19 13:59, Joseph Eisenberg wrote:
> Has this wikibase feature been discussed and approved by the community
> in some forum? Perhaps it happened before I was involved with OSM? I
> don't quite understand how it works.

The way it works is that every tag has a "data item". This is the one
for natural=isthmus, for example:

https://wiki.openstreetmap.org/wiki/Item:Q19327

Of course, you're not expected to find this numeric URL yourself. You
can get there from the wiki page for that tag by clicking on a "pencil"
icon next to the description in the infobox, or by using an
"OpenStreetMap Wiki data item" link that appears in the left-hand menu
on every page that has a data item associated with it.

The idea behind data items is actually quite similar to how templates on
the wiki work: There is a number of possible properties that you can
fill in with information. The properties which are currently available
are mostly identical to the ones used by the templates: Whether the tag
can be used on nodes/ways/..., links to related/required/implied tags,
an image, and descriptions in various languages.

If some information is omitted from a wiki page, the infobox will pull
it in from the tag's data item. Otherwise, the information written
directly on the page will take precedence.

A potential benefit of data items is that language-independent
information does not need to be manually copied to each translation. And
while software like Taginfo has been able to extract information from
the wiki for a long time, the hope is that this kind of extraction will
eventually become easier thanks to data items.

I do not believe there has been a community decision to stop adding
information directly on wiki pages. So the other wiki contributor's edit
was probably premature.

Of course, though, the current situation with content duplicated between
data items and wiki pages isn't really ideal. But there's probably still
some work left until data items can fully replace the existing systems
(updating data consumers, plus working on usability and documentation).

Tobias

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

Re: [OSM-talk] An Archive namespace for the OSM wiki?

[Tobias Knerr]

On 21.04.19 07:44, Yves wrote:
> Is there a way to decrease the rank of some pages in the search results
> in MediaWiki?

The possibility of increasing/decreasing the priority of certain search
results based on templates is being discussed at the moment as part of
this topic:
http://wiki.osm.org/Talk:Wiki#Proposal:_new_namespace_for_tagging_proposals

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

Re: [OSM-talk] An Archive namespace for the OSM wiki?

[Tobias Knerr]

On 20.04.19 09:24, Jochen Topf wrote:
> So as always you have to look at each case. If a page contains content
> that is still useful for our current world, keep it. But if something is
> merely interesting for historical reasons then it can be deleted. And
> yes, there is a gray area there, but humans can be trusted with these
> decisions and the world will not end if occasionally somebody makes the
> "wrong" decision. But stalling any progress in the wiki by requiring
> discussions about any change is certainly not the right way.

I'm in full agreement with the overall sentiment, and this paragraph
sums up a lot of my objections to the proposed deletion policy.

However, I believe that a lot of the social conflicts surrounding this
topic are caused by how MediaWiki implements "deleting" things: Only
admins can restore a deleted page or even view its history. In contrast,
everyone can undo a regular deletion in the OSM database (at least in
theory), and the history remains publicly visible.

So after a similar discussion several years ago, we created this
template for archiving proposals:
https://wiki.osm.org/Template:Archived_proposal

It basically amounts to removing a page's _contents_ (but not the page
itself or its history) and replacing it with a link to a previous
version of the same page that still had the original content. There's
also typically some basic information left on the page so that users
arriving from an external link know what they are looking at. This is
what a proposal "archived" in this style looks like:
https://wiki.osm.org/Proposed_features/barriers

It mostly achieves the same goal as deletion, especially reducing the
likelihood of getting in the way of searches (because there's little
content left to be indexed). Actually, it may do so a bit too well –
I've always been a bit concerned that it makes it hard to find old
proposals even when you're explicitly looking for them – but because
there are other approaches for finding proposals in particular (the RFC
mails, and the infobox links on key/tag pages back to the proposal),
they can still be found reliably.

The main benefit, though, is the ability for others to easily revert
this kind of change. It's easier to be bold in cleaning up the wiki when
you know that that others can quickly undo any edits they dislike.

Tobias

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

Re: [Talk-de] Besorgt über den iD-Editor

[Tobias Knerr]

On 29.03.19 15:32, Frederik Ramm wrote:
> Zugleich
> äussern sich die Entwickler gern auch mal geringschätzend über das Wiki
> oder Tagging-Diskussionen und nehmen sich eben das Privileg heraus, neue
> Features einfach einzubauen, die sie gut finden

Das scheint die herrschende Einstellung zu sein, ja. Zitat Bryan Housel
frisch von letzter Woche: "I basically just disregard everything on the
tagging mailing list and the OSM wiki."

https://github.com/openstreetmap/iD/issues/5835#issuecomment-477696136

Das ist natürlich nicht die erste entsprechende Äußerung und der Link
wirft auch sonst kein schönes Licht auf die iD-Entwicklung: Bryan äußert
sich negativ über die Community, vertritt kontroverse Taggingansichten,
die er via iD durchsetzen will, und sperrt beim Aufkommen von Kritik die
Github-Diskussion für Nichtentwickler. Letztlich geht es auch hier
wieder nur um eine Kleinigkeit, aber das Gesamtbild aus diversen solchen
Vorfällen macht auch mir inzwischen Sorgen.

Dass das alles mittelfristig ein Problem fürs Projekt werden kann, ist
aus meiner Sicht ziemlich offensichtlich. Bei der Frage nach Lösungen
würde ich mich im Großen und Ganzen Michael anschließen. Die wesentliche
Hürde für eine (über die Kritik an Einzelentscheidungen und eventuelle
Eskalation via Abstimmungen und DWG hinausgehende) Reaktion ist m.E. das
Fehlen plausibler Alternativen. Wenn sich jemand fände, der eine auf
Community-Konsens zurechtgestutzte Version der Tagging-Vorlagen von iD
pflegt, sähe das schon ganz anders aus.

Viele Grüße,
Tobias

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

Re: [OSM-talk] Questionnaire

[Tobias Knerr]

On 23.03.19 12:05, John Whelan wrote:
> You posted the same message in the HOT mailing list.

The same message was also sent to personal mail addresses of OSM
contributors yesterday, presumably scraped from mailing list archives.

Additionally, it was posted to several other lists on the lists.osm.org
server – including ones where it is quite off-topic, like the mostly
dead "party" list¹.

Overall, this is the 5th time I'm receiving a copy of this questionnaire
link. I can't help but feel we need to encourage a better approach for
polling the OSM community. Preferably one that also involves some
feedback from people with OSM experience before the survey is sent out.

Tobias

¹ https://lists.openstreetmap.org/listinfo/party

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

Re: [OSM-talk] Proposed mechanical edit - elimination of osmarender:nameDirection - blatant tagging for the renderer

[Tobias Knerr]

On 15.03.19 21:13, Simon Poole wrote:
> Why would we want to create new versions of objects just to remove a tag
> that is not hurting anybody in any way?

Mostly for the reason which Mateusz has mentioned in his response:
Keeping obsolete tagging around for years or decades adds to the burden
of concepts that new community members need to learn to fully understand
our data.

But additionally, I would argue that removing them all at once actually
results in a cleaner history than automatic removal by editors. It seems
to me that performing these edits in one clearly labelled changeset fits
our best practices – grouping related edits into a changeset and using
meaningful changeset comments – much better than mixing them into
completely unrelated changes would.

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

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

[Tobias Knerr]

On 10.03.19 19:20, Tom Pfeifer wrote:
> Eigenschaften, die das ganze Gebäude betreffen, sollten daher auf dem
> Gebäudeumring liegen, der auch ohne 3D-Mapping da wäre. Also auch die
> Adresse.

Ja, solche Relationen werten normalerweise nur 3D-Renderer aus. Die
Informationen, die auch andere Anwendungen brauchen, sind daher am
Umriss besser aufgehoben.

Als "belastbare Doku" würde ich "Simple 3D Buildings" heranziehen, den
Taggingstandard fürs 3D-Mapping: "Building attributes (e.g., address,
name, overall height, operator, etc.) must be tagged on the building
outline."¹

In diesem Beispiel ist die Relation übrigens auch für 3D eigentlich
nicht notwendig: Sämtliche Gebäudeteile liegen innerhalb des Umrisses
und es gibt keine Überlappungen/Mehrdeutigkeiten mit anderen Gebäuden.

Tobias

¹ https://wiki.osm.org/Simple_3D_buildings#Building_outlines

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

Re: [OSM-talk] We need to have a conversation about attribution

[Tobias Knerr]

On 28.02.19 23:35, Richard Fairhurst wrote:
> The policy, introduced with the changeover to the ODbL, says:
> 
> "We require that you use the credit “© OpenStreetMap contributors”...
> For a browsable electronic map, the credit should appear in the corner
> of the map."

As you seem to remember what was going on at the time, maybe this is an
opportunity to get an answer to a question that I've raised back in
2012, but (iirc) never got a response to: Who made the decision to add
this requirement to the copyright page?

https://lists.osm.org/pipermail/legal-talk/2012-October/007306.html

I don't perceive off-map attribution as a recent trend: This style of
OSM attribution was reasonably popular even back then, especially in
mobile apps. And I don't remember any widespread calls for restrictions
on the practice. In fact, the only mailing list discussion I recall is
the one linked above, which had barely any participants: Three people
questioning the then-recent change¹, and no one showing up to explain or
defend it.

So while I would agree that it's important for data users to respect the
community's policies, it's not yet clear to me that these highly
specific requirements on attribution placement did originate with the
community in the first place.

> a) we are happy for attribution to be behind a credits screen and we
> will update our requirements to say so

This is my personal preference, but I would still require equal
prominence with other brands. Showing "Mapbox"² on-map, but moving OSM
elsewhere, does not feel fair.

Especially in situations where a data user does make other efforts to
put OSM in the spotlight – e.g. by telling the user about OSM during map
downloads or through a long-lived, or interactive, splash screen – I
believe we should not insist on the corner placement.

Tobias

¹ the rest of the thread is split off due to happening in a different
month: https://lists.osm.org/pipermail/legal-talk/2012-December/007363.html
² My intention isn't to single out Mapbox here, that's simply the
example that's already been used in this thread.

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

Re: [OSM-talk] Bot edits on the OSM wiki

[Tobias Knerr]

On 24.02.19 20:18, Christoph Hormann wrote:
> I mainly wanted to make everyone who is not active on the wiki aware of 
> this.

For the benefit of people who don't know the background, it's worth
mentioning that these bot edits did not distort the actual meaning of
the wiki pages, but were purely performing a trivial technical
maintenance task.

Here's an example:
https://wiki.osm.org/w/index.php?title=Tag:waterway%3Driverbank=1805725=1650789==2015

To explain what's going on: The infoboxes on tag documentation pages are
available in different languages. In the past, users editing the wiki
had to manually set the desired language for the infobox with parameters
such as "lang=en". That's no longer necessary because the infobox now
automatically recognizes that it's part of an English page, and that it
should probably display "Description" rather than "Descripción" or
"Beschreibung".

So as there is no longer a point in having "lang=en" parameters, they
were recently removed by a bot. These edits are marked as bot edits,
which not only makes it transparent that the edit was performed by a
bot, but also solves the practical issue of watchlist spam (because such
edits can be easily filtered out from the watchlist).

Note that this wasn't some AI making decisions on its own, either, but
simply a human editor deciding to remove a particular line of text from
more than one wiki page at the same time. The bot API is just a tool
that makes this process less tedious.

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

Re: [Talk-de] Experimentelles Öffnungszeiten-Webtool

[Tobias Knerr]

On 19.02.19 09:24, Stefan Keller wrote:
> Fernziel ist u.a., den Tag "opening_hours:url" zu verwenden, um den
> dort verlinkten Webinhalt in opening_hours zu wandeln.

Finde ich eine spannende Vision, denn so könnten Änderungen bei den
Öffnungszeiten viel schneller entdeckt werden. Für OSM ist zumindest in
Europa die größte Herausforderung ja zunehmend das Aktualisieren (statt
Ersterfassen) von Daten.

> Feedback willkommen - hier oder als Issue im Repository!

Meine einfachen bis mittelschwierigen Tests haben beide
Implementierungen anstandslos geschluckt!

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

[Talk-de] Kandidatur für den OSMF-Vorstand

[Tobias Knerr]

Hallo zusammen,

ich habe dieses Wochenende erfahren, dass Peda (Peter Barth) aus dem
Vorstand der OSMF ausscheiden und nicht erneut kandidieren wird. Peda
hat aus meiner Sicht einiges erreicht, was das reibungslose
Funktionieren unseres Projekts, die Transparenz der Arbeit des Boards
(z.B. durch öffentliche Vorstandssitzungen und die Veröffentlichung von
Abstimmungsergebnissen), das Bekenntnis zu freier Software und offenen
Kommunikationsplattformen und nicht zuletzt die Vertretung der
Interessen von ehrenamtlichen Mappern angeht. Ich glaube, dass Peda auch
deshalb wertvoll für die Community war, weil er derzeit als einziges
Boardmitglied keiner Firma oder humanitären Organisation mit
geschäftlichen Interessen an OSM angehört. Für seine gute Arbeit möchte
ich ihm hiermit herzlich danken!

Da es mir wichtig ist, dass diese gute Arbeit auch in den kommenden
Jahren fortgeführt werden kann, werde ich mich für den Vorstand der OSMF
zur Wahl stellen. Ich bin in der OSMF seit 2009 Mitglied und auch in
einigen OSMF-Arbeitsgruppen gelegentlich aktiv. Vor allem aber bin ich
seit langem als Mapper und inzwischen auch als Hobby-Entwickler in der
OSM-Community zu Gange. Auch aus dem Forum oder Wiki dürften mich einige
von euch schon kennen.

Ausführlichere Infos liefere ich später noch nach, auch über die
offiziellen Kanäle: Es soll auch dieses Mal wieder Wahlprogramme sowie
die Möglichkeit zum Einreichen von Fragen an die Kandidaten geben. Da
die Vorstandswahl im deutschen Forum dank der fleißigen
Mitgliederwerbung von Nakaner aber bereits Gesprächsthema ist, wollte
ich den sprichwörtlichen Hut schon einmal in den Ring werfen. Und
natürlich dürft ihr mich auch jetzt schon mit Vorschlägen, Kritik und
Fragen löchern!

Viele Grüße,
Tobias

( Crossposting von https://forum.osm.org/viewtopic.php?id=64360 )

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

Re: [OSM-talk] OSM Wikibase is now live

[Tobias Knerr]

On 23.09.2018 17:07, Christoph Hormann wrote:
> If you'd now impose 
> technical constraints preventing mappers from documenting things that 
> do not match a certain ideal of structure would you would effectively 
> make the wiki unsuitable for its primary application and mappers would 
> need to set up a new place to document their tags.

The content stored in Wikibase is editable by wiki users using a regular
wiki account, same as with other wiki pages.

Ultimately, this is simply a different implementation of the infoboxes
that already exist on the wiki's key and tag pages. An implementation
that will be easier to maintain and easier to parse for projects like
Taginfo (which already parses today's infoboxes, but has to jump through
a lot of hoops to do so). But it isn't any more restrictive than filling
in the parameters of today's infobox.

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

Re: [OSM-talk] OSM Wikibase is now live

[Tobias Knerr]

On 23.09.2018 14:05, Michael Reichert wrote:
> Currently, the search of the wiki is not really useful any more.

Indeed, the search field is pretty much broken at the moment.

However, this has been brought up on the wiki talk page, and Yuri said
he was looking for a fix. So I think it's safe to say that this is not
intended behavior, at least.

> I suspect that the attempts for more structured metadata won't be really
> accepted by the community (the editors of the wiki).

As one of the more active editors of the wiki, I'm very hopeful for this
project. The current "solution" for this kind of data is to manually
copy templates across several pages. This is a massive pain point and
leads to pages unintentionally getting out of sync all the time.

Of course, it's still too early to say whether the idea will work out.
But I'm willing to help it succeed.

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

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

[Tobias Knerr]

Am 18.09.2018, 16:21, schrieb Benedikt Bastin:
> Gibt es abseits des Zugehörigkeitsproblems noch weitere Sachen, die gegen 
> eine solche Relation sprechen?

Im Allgemeinen tendiert der Konsens in der Community dahin, Relationen
nur dort zu verwenden, wo sie notwendig sind.

Aus diesem Grund ist auch in Simple Indoor Tagging anders als bei dem
von dir verlinkten älteren Indoor-Proposal vorgesehen, dass der
Gebäudeumriss + level-Tags an den enthaltenen Elementen für die
Zuordnung zum Gebäude ausreichen soll.

Einen sehr ähnlich gelagerten Fall gibt es übrigens bei
3D-Gebäudemapping: Auch dort ist die Nutzung von Relationen zur
Zuordnung von Gebäudeteilen zum Gesamtgebäude in den allermeisten Fällen
optional¹ und unüblich – die weit überwiegende Mehrheit der 3D-Gebäude
verzichtet darauf.

Wenn du dennoch eine Relation verwenden willst, dann ist die
building-Relation die gängigste Wahl. Ich würde aber wie gesagt eher
davon abraten. Auch eine geringere Fehleranfälligkeit von Relationen
halte ich in der Praxis nämlich nicht für gegeben: Es ist einfach zu
schnell passiert, dass ein Mapper z.B. ein neues Objekt ergänzt, es aber
nicht zur Relation hinzufügt.


¹ Ausnahme ist die Klärung von Zuordnungsproblemen bei überlappenden
Gebäudeumrissen

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

Re: [OSM-talk] Need some help regarding GSOC

[Tobias Knerr]

Hello Vasu,

thank you for your interest in participating in Google Summer of Code at
OpenStreetMap!

On 13.09.2018 20:30, vasu dev Singh wrote:
> I want
> to do a project with OpenStreetMap but I don’t know how to start.
One trait we're looking for in GSoC students is familiarity with the OSM
community. So at this point, it might not be a bad idea to do some
mapping in your local area, to explore the ecosystem of OSM-based
software, and so on.

In 2019 (assuming OSM will be selected as a mentoring organization), we
will publish a list of project ideas, much as we did this year. At that
point, you will be able to get in contact with the mentor(s) of the
specific ideas you are interested in, who may be able to suggest some
preparations more closely related to the development project in question.

Of course, you can also get in contact with developers directly if you
already know that you're interested in a particular open source project
under the OSM umbrella.

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

Re: [OSM-talk] Barrier=block areas

[Tobias Knerr]

On 15.08.2018 20:49, Tomasz Wójcik wrote:
> Currently, barrier=block is not allowed to be mapped as an area. As
> blocks can be big enough to map them as areas, I think it should be
> allowed, the same as in barrier=wall or barrier=hedge.

For routing purposes, barriers are usually connected to the highway=*
way somehow. When barriers are mapped as nodes, this is achieved by
tagging one of the way's nodes with the barrier tags.

How would we do this for barrier=block mapped as areas?

Note that the block(s) will not always be exactly on the centerline of
the highway, so we may not be able to even share a node between the area
outline and the highway way if we want to accurately represent the area
covered by the block. Due to this, I see no easy solution to map blocks
as areas while still making them topologically part of the routing network.

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

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

[Tobias Knerr]

On 08.08.2018 12:49, Tomasz Wójcik wrote:
> Due to our rules, that we shouldn't have 2 active tagging
> schemes for the same feature

These tagging schemes are for 2 different real-world features:
* roads/paths (i.e. linear features with a direction)
* plazas/squares (i.e. open areas where people will walk across in all
directions)

Linear roads/paths are mapped as highway=* ways, optionally with an
additional area:highway=* polygon.

Plazas/squares are mapped as highway=* + area=yes polygons.

So the area:highway key is never an alternative to highway polygons with
area=yes! In any given situation, only one or the other will be correct.

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

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

[Tobias Knerr]

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

Ich stimme zu, dass es einen Unterschied macht. Schöne Tagging-Lösungen
kenne ich allerdings nicht. Wenn man das erfassen will, bleibt einem
derzeit nur, das Ergebnis der Überschlagsrechnung als height-Tag am
Gebäude zu hinterlegen.

Im Prinzip könnte ein Renderer natürlich abhängig von
building:architecture, start_date oder ähnlichen Schlüsseln
unterschiedliche Default-Stockwerkhöhen annehmen. Allerdings weiß ich
bisher von keinem 3D-Renderer, der das tut.

> Ausserdem haben Gebäude in der Stadt oft so ein "Hochpaterre" (?), wo
> das Erdgeschoss nicht auf Straßenniveau ist, sondern einen halben Meter
> drüber. building:levels=3.5?

Das ist ein häufiger genanntes Problem, für das es meines Wissens
ebenfalls noch keine Lösung gibt – Interesse hätte ich und würde das
z.B. auch in OSM2World gerne einbauen.

Nicht ganzzahlige building:levels-Werte sind leider nicht gut
auszuwerten, weil man nicht weiß, _wo_ am Gebäude das halbe Stockwerk
ist. Das ist für die reine Höhenschätzung kein Problem, wohl aber wenn
man z.B. Fensterreihen einzeichnen oder Indoor-Mapping ins Gebäudemodell
einpassen will.

Theoretisch gäbe es sogar eine Lösung unter Verwendung von bestehenden
Tags, nämlich Simple Indoor Tagging: Man kann eine Fläche fürs
Erdgeschoss einzeichnen (indoor=level + level=0) und mit min_height=0.5
taggen. Aber eigentlich sollte ein so häufiger Fall einfacher abzubilden
sein, vor allem ohne den Pflegeaufwand von zusätzlicher Geometrie...

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

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

[Tobias Knerr]

On 03.07.2018 10:28, Frederik Ramm wrote:
> Don't forget that new FIXMEs will continue to appear all the time.

They will, but at a lower rate. Mappers often look at existing tagging
to find out how things should be tagged. This is further reinforced by
tools such as JOSM's autocompletion. Thus, I believe the current dataset
should always be as.clean as possible in order to set a good example.

Mostly eliminating the FIXME spelling now (instead of waiting for it to
disappear naturally over the next decade) will also allow us to simplify
the wiki documentation a little bit, get rid of special cases in tools
and so on. That may only be a small benefit, but it's the sum of all
these small exceptions, duplications and special cases that make
learning the OSM data model unnecessarily hard for mappers and data
consumers alike.

> Software should be able to deal with both.

In my opinion, software should not _need_ to deal with both. Working
around easily fixed database quality issues is a waste of time.
Especially when there's even a volunteer eager to fix these quality issues!

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

Re: [OSM-talk] proposed mechanical edit - moving building=building to building=yes

[Tobias Knerr]

On 08.06.2018 19:19, Mateusz Konieczny wrote:
> building=building is an unexpected way to mark building without
> specifying its type and therefore retagging this duplicate to
> building=yes would improve tagging without any information loss.
I'm in favour of proceeding with the proposed mechanical edit. The tag
change in question is doubtlessly an improvement, and the plans are
thoroughly documented. :)

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

Re: [OSM-talk] Open sourcing of POI pictures for OSM App/STAPPZ - Feedback and ideas wanted

[Tobias Knerr]

Hi Tim,

On 16.05.2018 10:16, Tim Frey wrote:
> I like the Wikipedia and in special the Wikivoyage direction also. Does
> somebody know the best touchpoints to get in contact with the community
> there?

I'm not familiar enough with their communities to give a recommendation.
However, Commons does "partnerships" with owners/maintainers of media
collections: https://commons.wikimedia.org/wiki/Commons:Partnerships
You could give the contact listed there a try.

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

Re: [OSM-talk] Open sourcing of POI pictures for OSM App/STAPPZ - Feedback and ideas wanted

[Tobias Knerr]

Hi Tim,

On 11.05.2018 17:19, Tim Frey wrote:
> Out of this, we consider, heavily, to “open source” the licensing of the
> user created STAPPZ content for the OSM community. In addition, we also
> consider to open source the backend of STAPPZ and the IOS and Android
> app to make a community project out of it.

I'm going to split this reply into two parts: About the content, and
about the software itself.


As for the content, a lot depends on if you can publish the images under
the terms of an open license.¹ That's a legal question, but probably
also a bit of a social one (i.e. would this be in line with what the
creators expected when they shared their images on your app, or would
they be unpleasantly surprised/unhappy about this).

Assuming the answer is that yes, you can publish them, the next question
is what to do with the images. OSM does not currently have an image
hosting platform, so if we're only talking about contributing the
images, they would need to be donated to a separate platform.

The obvious recipient for such an image donation would be Wikimedia
Commons, as they're the most popular repository for open-licensed media.
Images on Commons can be linked with OpenStreetMap POIs² and are used as
such by some OSM-based maps. Of course, they're also used by Wikipedia
and its sister projects – notably Wikitravel, which is a crowdsourced
travel guide (although much closer to the traditional book format than
your project).

A caveat is that such a donation would likely require some manual effort
to filter out lower-quality pictures or duplicates, and to add
meaningful descriptions. Still, assuming the legalities work out, it
seems feasible to donate the images and would be a generous contribution
to the open content ecosystem.


Ok, so let's talk about the app and backend a bit. I'm not sure how
familiar you are with OSM's organizational model, but as a rule we're
very decentralized – even core components of OSM are being developed as
mostly independent Open Source projects. For you, this means that even
if there's community interest, any re-use of your project would probably
still start out with _you_ spearheading its development, re-imagining it
as something you believe fits a need of the OSM community, and trying to
gain mindshare in the OSM contributor and developer community. Of
course, this may be at odds with your goal to focus on other projects.

If this does not discourage you, though, let's consider what needs the
software could serve. I don't have any amazing ideas to offer, but I
could see two basic roles in the OSM ecosystem an image platform might
potentially be able to fill. Broadly speaking:
* Images could be used internally by OSM contributors as a data source
for mapping in addition to sources as aerial imagery and GPS tracks.
* Images could be displayed by user-facing sites and apps alongside OSM
data. (I believe this is what you were getting at with your Google Maps
comparison.)

The former use case is already partially covered by
Mapillary/OpenStreetCam, so the question is if there's enough of a niche
left for another app.

The latter seems more ambitious. As I mentioned before, mappers are
currently using tags like image=* with links to external platforms to
add images to OSM POI. Those links can technically point anywhere,
although Wikimedia Commons currently appears to be the most popular
platform to host the images. Inviting users (including non-mappers) to
easily contribute images to a dedicated, OSM-affiliated platform might
be a worthwhile cause. Not sure how well this fits your platform's
existing social features, though.

Tobias


¹ Typically one of the open CC licenses: CC0, CC-BY or CC-BY-SA.
² Using http://wiki.osm.org/Key:image
or http://wiki.osm.org/Key:wikimedia_commons

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

Re: [OSM-talk] [Diversity-talk] How do you mapping gender neutral toilets? What should the unisex tag mean?

[Tobias Knerr]

On 25.04.2018 15:23, Martin Koppenhoefer wrote:
> Unisex=yes is defined as a shortcut for male=yes + female=yes

This may be a stupid question, but where are you all getting this
definition from?

I assumed the key already had the meaning that Rory is suggesting here.
And at least on the Key:unisex and Tag:amenity=toilet wiki pages, I see
nothing to contradict that.

The former page mentions that the tag implies male=yes and female=yes,
but "implies" should not be confused with "is equivalent to".

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

Re: [OSM-talk] Sidewalk symmetry

[Tobias Knerr]

On 24.04.2018 02:17, Clifford Snow wrote:
> But if you want
> someone to use the data, then map it as separate ways. 

That's not the case, and it's a bit frustrating to read this just after
I wrote a mail explaining this point. To reiterate:

* With separate ways, we don't know which road section a sidewalk
belongs to.
* This knowledge is necessary for many applications.

For such a fundamental property, "research scientists believe they can
use the spatial proximity" is not good enough imo. It has to be
practical to obtain this relationship from OSM data.

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

Re: [OSM-talk] Name:* tags in the local language

[Tobias Knerr]

On 24.04.2018 19:23, Paul Norman wrote:
> It is sometimes recommended that when you add a name in another language
> you also indicate the name in the local language by adding a suitable
> name:* tag at the same time. For example, if adding "name:fr=Londres" to
> London, you would also add "name:en=London" if it weren't present.
> 
> This practice is not widely followed.

I have to say I'm not a fan of this practice, at least for
straightforward cases.

Yes, there are parts of the world where explicit language information is
necessary. But in many others, there is an obvious default, and it feels
wrong to require mappers to manually repeat this on millions of
individual elements. Don't add extra tags to German names in Germany,
for example – tag the exceptions from the rule instead.

As a less important secondary point, I also consider the specific
tagging (duplicating the name with a different key) counter-intuitive
and would prefer a "language of the name" key, with the language given
as the value. The purpose of that tag would be much more
self-documenting than with the recommendation described above.

That being said, displaying labels in the user's language is an exciting
use case, and I hope we can find a solution that allows your project to
succeed. Could you elaborate a bit more on the technical limitations
regarding regional processing?

> Fixing this in software doesn't work
> well because it requires regional processing of what are increasingly
> small regions as you get to less used languages.

You mention increasingly small regions as the obstacle. Would that still
allow for the pragmatic compromise of setting country-level defaults,
and using explicit tagging only for smaller-scale language regions?

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

[OSM-talk] Sidewalk symmetry

[Tobias Knerr]

On 18.04.2018 05:03, Andrew Harvey wrote:
> highway, surface, maxspeed, maxweight, maxheight, width, oneway, access,
> lanes, turn:lanes, lit, parking:lane:left, parking:lane:right,
> parking:condition:left, parking:condition:right,parking:lane:left:type,
> parking:lane:right:type, etc.

The percentage of roads tagged with all these details is vanishingly
small, and will likely remain so for at least another decade.

At the level of detail that's realistically achievable in the medium
term, sidewalk tags make a lot of sense: They're easy to use for the
common case (where sometimes not even the existence of sidewalks is
mapped yet), and still allow for micromapping in pockets of unusually
high data quality.

> I realise editors can and do abstract some of this, but if we can put
> all those sidewalk attributes on their own ways it makes it much easier
> to map by reducing the complexity of the highway centerline.

Comparing the mapping styles solely based on ease of mapping would only
make sense if separate ways were able to express the same information
contained in sidewalk tags.

That's not the case, though: With separate sidewalk ways, it's
impossible (in the general case) to figure out which road section that
sidewalk way belongs to.

Not having this basic information available makes separately mapped
sidewalks unusable for entire categories of applications – sometimes
leading to worse outcomes than not having the sidewalk mapped at all.
And while you could fix that issue with relations, this would clearly
not be easier for mappers than using sidewalk tags is.

As for the original question: sidewalk=separate seems like an attempt to
solve the aforementioned issue, but it does not actually achieve this
goal – it only tells you that *some* sidewalk way belongs to this
section of road, but does not help you to find out *which* sidewalk way
that is. As such, it's not a very useful tag, and not a compelling
reason to map asymmetric real-world situations in a symmetric way.

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

Re: [OSM-talk] How to teach novices about optimal changeset size?

[Tobias Knerr]

On 17.01.2018 18:47, Rory McCann wrote:
> Users want to save/upload frequently (because computers), so we'll never
> stop them pressing the button often.

But we could give them more than one button.

There's "save", and then there's "upload/commit/publish". The two
actions are distinct, and part of the problem may be that online editors
tend to merge them into a single concept.

I'm also used to saving frequently, but because JOSM cleanly separates
save and upload, my habit doesn't get into the way of grouping my
changes into a cohesive changeset with a fitting description when I'm
finished.

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

Re: [OSM-talk] Automatically generated changeset discussion comments by OSMCha

[Tobias Knerr]

On 13.01.2018 11:02, joost schouppe wrote:
> - a reviewer in OSMcha can adapt the message to his own personal message
> or an ad hoc message
[...]
> - a reviewer can choose to not send a message if they feel like they're
> spamming

Those would be steps in the right direction, but I wonder why it's
necessary to even pre-fill a default message at all? I'd suggest to
leave it blank and have people compose their own messages.

Now ideally, those would be tailored to each changeset and mention
something that demonstrates you actually looked at the new user's work
(and in a perfect world, demonstrates local knowledge to show that
you're from the area).

But even if the reviewer writes a message only once and re-uses it for
subsequent changesets (which OSMCha could even make easier by
remembering your previous messages), that message will still be
infinitely better than the current default, as it's likely to be in the
local language, follow local communication styles, and have an
individual touch from the human mapper who wrote it.

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

Re: [OSM-talk] Automatically generated changeset discussion comments by OSMCha

[Tobias Knerr]

On 12.01.2018 15:39, Andy Townsend wrote:
> More seriously, any automatic use of OSM messages is problematical
> because it devalues the messages that we want people to actually read -
> the ones that are composed by and sent be a human, and have actual
> useful information in them

I agree. Right now, messages and comments sent via OSM channels tend to
be written by humans for a specific individual recipient, which gives
them a very good signal-to-noise ratio. I enjoy that a lot and would
like to keep things that way.

Subjectively, I also tend to find it a bit off-putting when canned
messages try to imitate human writing. Compared to obviously automated
messages ("your changeset was reviewed by user X"), they can feel
somewhat dishonest. I accept that people will feel differently about
this, though.

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

Re: [Talk-de] routing.openstreetmap.de

[Tobias Knerr]

On 31.12.2017 10:25, Volker Schmidt wrote:
> Die drei im vorliegenden Fall vorhandenen einschraenkenden
> tags beziehen sich ausschliesslich auf motorisierte Fahrzeuge; daher sollte
> der Router Fussgaenger, Radfahrer und Reiter durchlassen.

Der Schlüssel access bezieht sich keineswegs nur auf motorisierte
Fahrzeuge, und der Way ist als access=agricultural getaggt. Richtig wäre
vermutlich motor_vehicle=agricultural.

Dass zusätzlich zum access-Tag auch noch Einschränkungen getaggt sind,
die sich nicht auf Fußgänger beziehen – nämlich motorcar=no und
motorcycle=no – ändert daran nichts.

Und um auch noch eine weitere Quelle der Verwirrung auszuschließen: Es
gibt "agricultural" auch als Schlüssel, wo es dann keine Nutzungsart,
sondern einen Fahrzeugtyp bezeichnet und Fußgänger daher nicht betrifft.
Das spielt für diese Diskussion aber keine Rolle, da hier der Wert
agricultural genutzt wurde, nicht der Schlüssel agricultural.

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

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

[Tobias Knerr]

Hi Roland,

On 04.12.2017 09:42, Roland Olbricht wrote:
> 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.

there's an important distinction here: It's Ilya's proposal that has
failed (for now at least), not the proposal process. That proposals are
sometimes rejected is an inherent part of that process.

I've written several proposals over the years, and while some of them
have been accepted, I've always learned something from the ones that
weren't. Just because I'm an experienced contributor doesn't mean all my
ideas are great – and the proposal process is a way to weed out those of
my ideas that aren't.

I'm not trying to suggest that the proposal system cannot possibly be
improved upon. However, Ilya's proposal was pretty unusual as far as
proposals go: It had a couple specific flaws which you already hinted at
(such as trying to do too much at once and writing in a "documentation
page" format instead of describing the changes to be voted on), so it's
likely not the best basis for generalizing observations to the proposal
process as a whole.

> I suggest to replace the Proposal process by three more specialized
> and therefore much simpler processes. They are structured by what they
> can affect.
[...]
> === Distinguished Documentation === [...]
> === Wiki Cleanup === [...]
> === Tag Disambiguation ===

At the moment, the proposal process isn't really intended for things
that _only_ affect the wiki, it's always an attempt to come to an
agreement on how to tag things in the database. So most of these items
seem to be outside the scope of what proposals are suitable for.
Generally, I don't believe a democratic process is the best way to
produce well-written documentation.

Tobias

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

Re: [OSM-talk] Woods vs Forests

[Tobias Knerr]

On 31.10.2017 07:59, Martin Koppenhoefer wrote:> one tag for what? An
area with trees? A forest? How would you define> "forest"?
One tag that can be used for mapping both the things currently mapped as
landuse=forest, and the things currently mapped as natural=wood.

Whether that is a tag for "forest" or for "tree-covered area" is a
worthwhile discussion. But going beyond that and asking for a precise
definition of "forest" seems like an almost impossible requirement, and
I'd rather have a less than perfect definition than no change.

> this is really a non-issue, just evaluate these 2 tags the same way and 
> you’re done.

That's an easy way out for data consumers, but not for mappers. When
mapping forests, you are currently forced to make a distinction that you
may not care about and that you may not even be qualified to make: You
can't just map a forest without also including a statement regarding its
naturalness or use for forestry purposes.

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

Re: [OSM-talk] weeklyOSM #379 2017-10-17-2017-10-23

[Tobias Knerr]

On 28.10.2017 12:06, Andrew Hain wrote:
> His behaviour over the past years makes him a contributor of net
> negative value.

I have to disagree here. He's probably the single most active wiki
contributor, and is also performing a lot of useful maintenance work
that no one else would bother doing.

His communication style needs to improve a lot, no doubt about that. But
even so, his contributions are still a net positive for OSM.

This does not mean that he should be exempt from the rules, of course.
To the contrary: What I would hope for is consistent enforcement of the
rules, with gradually increasing penalties. Jumping straight from spotty
enforcement to a permanent ban, though, seems wasteful and needlessly cruel.

Tobias

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

Re: [OSM-talk] Woods vs Forests

[Tobias Knerr]

On 27.10.2017 00:49, Dave F wrote:
> The woods/forest problem is one of the worst tagging cock-ups in OSM.

Indeed. The current mess is especially disappointing because it hasn't
always been that way: The status quo is the result of an attempt to
"improve" the tagging years ago.

From my point of view, it's plainly obvious that there should be only
one main tag instead of two.

Details on whether the area is used for forestry, whether it is in a
"natural" state (whatever that means), or other such information can be
gathered in addition to that main tag. Gathering that secondary
information should not be a requirement for being able to map the
forest/wood in the first place.

> all areas of trees should
> be primarily tagged as natural=wood. As with other entities, any further
> details which gives clarity should be provided in sub-tags.

That would work nicely as far as I'm concerned.

Tobias

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

Re: [OSM-talk] WhatOSM, a guide for contribution tools

[Tobias Knerr]

On 21.09.2017 19:45, PanierAvide wrote:
> http://projets.pavie.info/whatosm/

This may be controversial, but I don't think a guide for people
considering to contribute to OSM should send them away to Mapillary.
They aren't part of OSM proper and arguably compete with us for
volunteer time. Mapillary let us use their images, of course, but they
have that in common with a lot of other orgs that no one would mistake
for being part of the OSM project.

> It can be used by new contributors, but also more experimented ones, who
> don't know what to do anymore in their neighbourhood.

For new contributors, the recommendations feel a bit too focused on
niche use cases, and not enough on core OSM. When people have a few
hours or days to spare and want to contribute to OSM, then I would
almost always recommend that they start mapping in their local area
using iD or JOSM (depending on computer skills).

Something else to consider is that "outside" and "remotely" does not
cover the entire OSM experience. In fact, the traditional way to
contribute is to collect data outside, and enter it back at home. Right
now, that's not an option with your tool.

Hope this mail doesn't come across as too negative! I mostly focussed on
potential improvements rather than the things that worked fine for me
(i.e. everything not mentioned here).

Tobias


 It might be
> interested to show this to people when doing mapping parties. User
> interface works as well on desktop as on smartphone.
> 
> This project is open source and is available on this repository :
> 
> https://framagit.org/PanierAvide/WhatOSM
> 
> You can contribute to it by proposing tools which allow contributing
> more or less directly to OpenStreetMap. Also, if you speak English +
> another language, you can help translating the application :
> 
> https://www.transifex.com/openlevelup/whatosm/
> 
> If you have any ideas or suggestions, let me know :-)
> 
> Regards,
> 
> Adrien.
> 



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

Re: [OSM-talk] Adding wikidata tags to the remaining objects with only wikipedia tag

[Tobias Knerr]

On 20.09.2017 17:02, Christoph Hormann wrote:
> It is best to regard the wikidata and wikipedia tags in OSM as 'related 
> features' rather than identical objects.

We shouldn't dilute the definition of the key because some incorrect
links exist in the database. If there's no 1:1 relationship between OSM
element and Wikidata item, and this cannot be fixed by editing Wikidata,
then no wikidata tag should be added.

> These provide useful sources 
> to research additional information (in particular wikipedia articles 
> often link to additional sources)

Sure, but the wikidata key is for "the Wikidata item about the feature",
not any related content that may be interesting.

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

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

[Tobias Knerr]

Hallo zusammen,

mir ist aufgefallen, dass Mentz beim Bahnhofsmapping eine inkompatible
Interpretation des Schlüssels building:part gewählt hat. Dieser kommt
bei Mentz für Indoor-Elemente wie Aufzüge, die nicht unbedingt einen
Einfluss auf die äußere Form eines Gebäudes haben, oder auch für
Tunnel[1] zum Einsatz. Auch Stockwerke werden in der Mentz-eigenen
Dokumentation[2] als Einsatzmöglichkeit erwähnt.

Das widerspricht allerdings klar der etablierten Bedeutung dieses
Schlüssels, der ja aus Simple 3D Buildings stammt. Um den bestehenden
Standard nicht zu gefährden, sollte hier ein anderes Tagging gefunden
werden. Daher würde ich hoffen, dass Mentz bereit ist, eine andere
Lösung zu wählen und ihre eingetragenen Daten entsprechend zu korrigieren.

Ich hatte das bereits vor zwei Wochen im Wiki angesprochen, aber keine
Reaktion erhalten:
http://wiki.openstreetmap.org/wiki/Talk:MENTZ_GmbH/Modellierungsvorschl%C3%A4ge_Indoor#Problematische_Nutzung_von_building:part

Gruß,
Tobias

[1] Beispiel: http://www.openstreetmap.org/relation/7103998
[2] http://wiki.osm.org/DE:MENTZ_GmbH/Modellierungsvorschläge_Indoor



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

[Talk-de] OSM-Events auf der FOSSGIS 2017

[Tobias Knerr]

Hallo zusammen,

lang ist's ja nicht mehr hin bis zur FOSSGIS in Passau. Daher zunächst 
mal die Erinnerung: Denkt daran, euch unter 
http://fossgis-konferenz.de/2017/anmeldung/ anzumelden!


Wie ihr vielleicht schon gehört habt, wird es auf der FOSSGIS dieses 
Jahr zwei OSM-spezifische Events geben, die auch unabhängig vom Rest der 
Konferenz besucht werden können: Am Nachmittag des dritten 
Konferenztages richten wir eine Mappingparty aus, bei der gemeinsam die 
Daten in der Passauer Altstadt verbessert werden. Der Tag darauf steht 
dann als "OSM-Samstag" komplett im Zeichen von OSM – das Programm wird 
im Stil einer Unkonferenz von euch selbst gestaltet.


Damit wir diese OSM-Events besser planen können, wäre es schön, wenn ihr 
euch bei Interesse vorher auf den entsprechenden Wikiseiten eintragt:


http://wiki.osm.org/FOSSGIS_2017/Mappingparty
http://wiki.osm.org/FOSSGIS_2017/OSM-Samstag

Viele Grüße,
Tobias

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

Re: [Talk-at] FOSSGIS 2017 - CfP endet HEUTE

[Tobias Knerr]

Zur Erinnerung: *Heute* endet die Vortragseinreichung für die 
FOSSGIS-Konferenz 2017 in Passau. Verlängern können wir die Frist 
diesmal leider nicht, also reicht schnell noch eure Ideen ein! Besonders 
aus Österreich vermissen wir noch Einreichungen, zumal die Konferenz 
doch quasi in eurem Vorgarten stattfindet – also, gebt euch einen Ruck! ;)


https://www.fossgis-konferenz.de/2017/callforpapers/

Falls euch die Zeit nicht mehr ganz reicht, stellt heute zumindest die 
Basisinfos ein. Am Abstract dürft ihr dann noch die nächsten Tage feilen.


Wer schon eingereicht hat: Danke für den Beitrag, das Programmkommittee 
wird sich nach Einreichungsschluss an die Arbeit machen und das Programm 
zusammenstellen. Wir haben nach dem aktuellen Stand schon viele 
interessante Vortragseinreichungen. :) Nichtsdestotrotz würden wir uns 
noch über weitere Vorträge aus dem OSM-Umfeld freuen!


Gruß,
Tobias

On 01.01.2017 21:16, Peter Barth wrote:

Hallo zusammen,

ich bumpe hier nochmal den Thread zur Erinnerung, da der 6. Januar  keine
Woche mehr entfernt ist und wir noch nicht genug Einreichungen haben.
Frederik hat das auf talk-de vor kurzem schon mal geschrieben
(https://lists.openstreetmap.org/pipermail/talk-de/2016-December/113735.html)
Ganz so schlimm sieht es nicht mehr aus, aber es ist noch zu wenig und
es hat doch sicher jeder von euch etwas interessantes zu erzählen! Also
los, nachdenken, einreichen und dann auf zur FOSSGIS-Konferenz 2017 in
Passau. Da Passau ja zudem fast in Österreich liegt, ist das für viele
von euch ein Katzensprung und z.B. die Linzer können da ja schon fast
einen Spaziergang draus machen ;-)

Und wo wir schon dabei sind könntet ihr euch auch gleich noch für den
OSM-Samstag im Wiki eintragen:
https://wiki.openstreetmap.org/wiki/FOSSGIS_2017/OSM-Events
Das erleichtert uns dann die Planung bzgl. Räumlichkeiten und
Verpflegung. Der OSM-Sonntag in Salzburg war wirklich genial; ich kann
euch nur empfehlen auch den OSM-Samstag in diesem Jahr nicht zu
verpassen!

Bei Fragen einfach hier oder direkt an mich oder an das Programmkomitee.
Ich freue mich über eure Einreichungen,
Peda


Peter Barth schrieb:


Hallo zusammen,

wie ihr vielleicht schon mitbekommen habt, haben wir doch noch einen
Austragungsort für die FOSSGIS-Konferenz 2017 gefunden! Und zwar freue
ich mich besonders, dass es die Dreiflüssestadt Passau, die zugleich
mein langjähriger Wohnort ist, geworden ist.

Veranstaltet wird die Konferenz vom FOSSGIS e.V. (http://fossgis.de) und
der OpenStreetMap-Community mit Unterstützung der Universität Passau
(http://www.uni-passau.de).

Im Jahr 2017 findet die FOSSGIS vom 22. bis 25. März an der Universität
Passau statt. Anläßlich des Erfolges im letzen Jahr wird es übrigens
auch dieses Jahr einen dedizierten OSM-Tag geben: Den OSM-Samstag am 25.
März, für alle, die es unter der Woche noch nicht zur Konferenz schaffen
oder noch mehr OSM wollen. Themen und Vorträge für diesen Tag werden wir
gesondert über das Wiki planen, mehr dazu später. Für alle anderen
Vorträge läuft der Call for Papers bis zum 06. Januar 2017!

Wir suchen: Deine Idee, Dein Projekt, Deinen Erfahrungsbericht, Dein
Thema. Genauer gesagt, suchen wir Vorträge für Einsteiger und
Fortgeschrittene, die spannende Themen behandeln und anregende
Diskussionen auslösen. Vorträge zum Thema freie Geodaten, zum Beispiel
OpenStreetMap oder Open Data sind ebenso möglich wie Beiträge zu
Lösungen mit freier Software aus dem Bereich WebGIS, Desktop GIS,
Geodatenbanken, Location-Based Services, etc.

Vorgesehen sind drei verschiedene Vortragsformate:

Es gibt 20-minütige *Vorträge*, in denen man über sein Projekt berichten
kann, ein Taggingschema oder Mappingpraktiken vorstellen kann oder auch
einfach nur über die eigene Aktivität als Mapper und z.B. die
verwendeten Werkzeuge sprechen kann. Die Themen bestimmt Ihr und wir
freuen uns über eine große Vielfalt an Themen, da genau diese Vielfalt
auch den Reiz unserer Konferenz ausmacht.

Für eher kleinere Themen oder wenn ihr euch keinen vollen Vortrag
zutraut gibt es auch die sogenannten *Lightning Talks*, das sind kurze
Vorträge von maximal 5 Minuten.

Und wenn ihr anderen gerne etwas beibringt und euch in einem Thema
besonders gut auskennt, gibt es noch die *Workshops*. Sie sollen in 90
Minuten den Teilnemern einen Mix aus Theorie und Praxis vermitteln. Bei
einer Workshop-Einreichung ist es wichtig, darauf zu achten, dass
erreichbare Lernziele und notwendige Vorkenntnisse der Teilnehmer
beschrieben sind. Vor allem aber stellen Workshops auch eine wichtige
Einnahmequelle für den FOSSGIS e.V. dar, da die Teilnahme
kostenpflichtig ist. Wenn ihr euch mit einem angedachten Workshop also
nicht sicher seid, kontaktiert uns, wir helfen gern.

Bitte reicht euren Abstract ab sofort bis zum 06. Januar 2017 ein. Eine
Fristverlängerung ist wegen der ohnehin straffen Zeitplanung *nicht*
vorgesehen.

Weitere Einreichungsdetails findet ihr auf unserer Konferenzseite

Re: [Talk-de] Bitte HEUTE Vorträge einreichen für die FOSSGIS-Konferenz

[Tobias Knerr]

Zur Erinnerung: *Heute* endet die Vortragseinreichung für die 
FOSSGIS-Konferenz 2017 in Passau. Verlängern können wir die Frist 
diesmal leider nicht, also reicht schnell noch eure Ideen ein!


https://www.fossgis-konferenz.de/2017/callforpapers/

Falls euch die Zeit nicht mehr ganz reicht, stellt heute zumindest die 
Basisinfos ein. Am Abstract dürft ihr dann noch die nächsten Tage feilen.


Wer schon eingereicht hat: Danke für den Beitrag, das Programmkommittee 
wird sich nach Einreichungsschluss an die Arbeit machen und das Programm 
zusammenstellen. Wir haben nach dem aktuellen Stand schon viele 
interessante Vortragseinreichungen. :) Nichtsdestotrotz würden wir uns 
noch über weitere Vorträge aus dem OSM-Umfeld freuen!


Gruß,
Tobias

On 01.01.2017 21:09, Peter Barth wrote:

Hallo,

und da wir jetzt ein neues Jahr haben bumpe ich den Thread nochmal und
erinnere daran, dass bis zum 6. Januar keine ganze Woche mehr ist. Also
bitte nutzt eure restliche vorlesungsfreie Zeit/Ferien/Urlaub/... noch
euch ein gutes Thema zu überlegen und einzureichen. Wir haben zwar die
Einstelligkeit der Einreichungen bereits überschritten, wollen aber noch
viel mehr ;-)

Außerdem könnt ihr euch gerne schon heute für den OSM-Samstag im Wiki
eintragen: https://wiki.openstreetmap.org/wiki/FOSSGIS_2017/OSM-Events
Das erleichtert uns dann die Planung bzgl. Räumlichkeiten und
Verpflegung. Der OSM-Sonntag in Salzburg war wirklich genial; ich kann
euch nur empfehlen auch den OSM-Samstag in diesem Jahr nicht zu
verpassen!

Bei Fragen einfach hier oder direkt an mich oder an das Programmkomitee.
Ich freue mich über eure Einreichungen,
Peda


Frederik Ramm schrieb:


Hallo,

   vielleicht erinnert ihr Euch an Peters Aufruf hier:

https://lists.openstreetmap.org/pipermail/talk-de/2016-November/113629.html

Es geht um die FOSSGIS-Konferenz, die im März in Passau stattfindet. Die
Vortragseinreichung läuft bis zum 6. Januar. Das hört sich lang an, aber
wenn man alle vor uns liegenden Feier-, Fest- und Reisetage abzieht, ist
das bei den meisten noch so etwa eine Woche ;)

Es wäre echt super, wenn sich aus unseren Reihen noch ein paar
Vortragende finden würden. Ich weiss nicht, ob ich das ausplaudern darf,
also sag ich es mal ganz vage: Bislang ist eine hohe einstellige Zahl
von Vorträgen eingereicht worden ;) Das reicht noch nicht *ganz* für
eine schöne Konferenz in Passau. Also - wer hat noch nicht, wer will
nochmal, ich weiss, dass unter uns viele sind, die etwas interessantes
zu OSM erzählen können, sei es aus Anwender-, Programmierer-, oder
Mappersicht.

Bitte lasst die Frist nicht verstreichen - wenn ihr eine gute Idee für
einen Vortrag habt, die aber noch etwas ausformulieren wollt, wäre den
Veranstaltern auch sehr geholfen, wenn ihr jetzt noch vor Weihnachten
eine Einreichung macht und Euch dann später nochmal einloggt und am Text
feilt (das geht im Interface problemlos) - besser als die Sache vor sich
herzuschieben und dann kommt ihr nicht mehr dazu ;)

Bye
Frederik

--
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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





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

Re: [OSM-talk] Map features page on wiki

[Tobias Knerr]

On 21.09.2016 01:33, Matthijs Melissen wrote:

I added it to the infobox as osmcarto-rendering.

It is currently only used in the supermarket page:
https://wiki.openstreetmap.org/wiki/Tag:shop%3Dsupermarket


Maybe I'm a bit late to the party, but I don't feel it's great to give 
special treatment to Mapnik in the infobox, and there is not enough room 
for presenting all the renderers there.


While placing the icon in the infobox is probably the easiest way to 
make it available to Taginfo, we shouldn't forget that it also 
determines how renderer support is presented on the tag pages. And in 
that regard, I find it's a less than ideal solution.


Quite some time ago, someone suggested a "Rendering" section on tag 
pages, with example images for all (or at least a wider selection of) 
renderers supporting the feature. This wouldn't be limited to icons, 
either, but would also work for area styles, for example. I would 
clearly prefer a presentation along those lines, as it would represent 
the diversity of OSM rendering in a way that a Mapnik icon does not.


Of course this leaves the issue how to implement something along these 
lines while still allowing Taginfo to access the content. I don't 
pretend I have a solution, but could this information be integrated into 
the Taginfo projects JSON somehow? If I remember correctly, there is 
already the possibility to add icon urls.


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

Re: [OSM-legal-talk] Use of data from the Malaysian government Open Data portal

[Tobias Knerr]

Hello,

On 2016-03-07, Jangan Kacau wrote:
> Recently, the data portal has released a list of route reference
> numbers, which can be accessed from the link:
> http://data.gov.my/view.php?view=921
> and I would like to use it to update OSM.

Section 3 could be a problem. As you know, users of OSM data must
attribute OSM, but we don't want to force them to list lots of other
data providers alongside OSM.

This section seems to require that users of the data (which would
include all users of OSM if this data is imported) provide attribution
to the Malaysian government. In that case, the data would not be usable
for OSM under the current licensing terms.

I'm not sure if my reading is correct, though. Could anyone confirm, please?

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

Re: [Talk-de] Lizenz für Programme und Code

[Tobias Knerr]

Am 01.03.2016 10:59, schrieb Markus:
> Was verwendest Du? wieso?

Meine bevorzugte Lizenz, gerade für kleinere Sachen, ist die CC0. Ich
bin generell ein Fan der "ganz freien" Lizenzen, weil ich möchte, dass
möglichst viele andere Entwickler meine Software als Grundlage nutzen
können und sich keinen großen Gedanken über rechtliche Fragen machen müssen.

Eine Ausnahme ist hier OSM2World, dort verwende ich die LGPL.

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

Re: [Talk-at] Filialen von Dayli und Schlecker

[Tobias Knerr]

Am 20.02.2016 18:42, schrieb Friedrich Volkmann:
> On 20.02.2016 14:27, Markus Mayr wrote:
>> Dem "shop=vacant" stehe ich skeptisch gegenüber.
> 
> Ich nicht. Wir mappen, was da ist. Ein leeres Verkaufslokal ist nicht
> , sondern ein leeres Verkaufslokal.

Ein leeres Verkauflokal ist aber kein Ort, wo man etwas kaufen kann,
d.h. es erfüllt die Definition des shop-Schlüssels nicht.

Da man für den shop-Schlüssel beliebig viele Werte erfinden kann, muss
sich ein Auswerter darauf verlassen können, dass alle Werte diese
Mindestanforderungen erfüllen.

> Leerstehende Lokale sind noch vorhanden (daher shop=*), aber man kriegt dort
> keine Kleidung (darum nicht shop=clothes).

Sie sind vorhanden, aber sie sind kein Ort zum Einkaufen (shop=*). Wenn
man sie taggen will, muss man also einen neuen Schlüssel erfinden, wie
eben disused:shop.

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

Re: [Talk-de] Treppen und Handläufe

[Tobias Knerr]

Am 15.12.2015 21:53, schrieb Thorsten Alge:
> kennt Ihr noch andere OSM-basierte Dienste als
> http://openls.geog.uni-heidelberg.de/wheelchair-test/ , welche die Tags
> highway=steps und handrail[:left|:right]=yes auswerten?

OSM2World wertet diese Tags aus. Allerdings sind die Handläufe zu klein,
als dass sie in der auf Zoom 18 limitierten Onlinekarte sichtbar wären.
Daher bemerkt man sie derzeit nur offline.

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

Re: [Talk-de] Problem mit Bahnhofsmapping von MentzDV

[Tobias Knerr]

Hallo Roland,

danke für deine Reaktion. Ich finde allerdings, du machst es dir da zu
leicht. Mit Weiterpflegen (aka Hinterherputzen) am Passauer Bahnhof ist
das Grundproblem nicht gelöst. Viele Fehler bei eurem Mapping sind
systematisch, und treten eben nicht nur in Passau auf.

Zumindest die folgenden Punkte sind wahrscheinlich Systemprobleme:
* Pseudo-Fußwege auf den Bahnsteigen
* Verwendung von level außerhalb von Gebäuden
* Mappen Bahnsteig-Verkaufsautomaten als "Kiosk"
* Getrenntmapping von Gehsteigen, wo 0 bauliche Trennung existiert
* Mapping von Bahnsteigdächern als Gebäude

Ich wünsche mir, dass ihr:
* diese Fehler bei allen bearbeiteten Bahnhöfen korrigiert
* diese Fehler in Zukunft nicht mehr macht.

Ansonsten kann ich in eurem Mapping keinen Gewinn für OSM sehen.

Dann noch im Detail zu deinen einzelnen Punkten:

Am 31.08.2015 10:56, schrieb Roland Olbricht:
> Wer sich über den jetzigen Zustand echauffiert, sollte allerdings auch
> mal einen Blick auf den Zustand vorher geworfen haben:

Sicher, der Zustand vorher war nicht perfekt. Es hätte für uns einfach
wenig Sinn ergeben, den Bahnhof detaillierter zu erfassen, da er seit
langem komplett umgebaut wird. Z.B. ist die Fußgängerunterführung schon
heute nicht mehr dort, wo sie war (und wo ihr schön detailliert den
alten Zustand eingezeichnet habt).

>> * Dann gibt es zig neue Bushaltestellen entlang der Straße.
[...]
> Die ganze Batterie mit wenigen Metern Abstand ist aber verdächtig.

Das ist insbesondere deshalb problematisch, weil die einzelnen Halte in
keiner Weise unter den gemeinsamen Namen der Haltestelle gruppiert sind.

> Generell gibt es für Fußwege die beiden Modelle, den Fußweg separat zu
> mappen oder den Fußweg über Attribute im Weg zu beschreiben, und beide
> stehen gleichberechtigt nebeneinander.

Das ist zugegeben eine laufende Diskussion, aber es gibt seit langem das
Kriterium der baulichen Trennung. Eine solche ist in dem Fall nicht
gegeben. Es besteht auch keine nennenswerte Komplexität, die eigene
Geometrie erfordern würde. Was vorliegt, ist einfach ein Gehsteig am
Straßenrand:
http://regiowiki.pnp.de/index.php/Datei:Bushaltestelle_Hauptbahnhof.JPG

Euer Mapping stellt die Situation übrigens ziemlich falsch dar:
* Der Gehsteig südlich von Weg 7718378 geht ganz bis rechts bis zur
Kreuzung, er endet nicht plötzlich.
* Es gibt auch an der Nordseite einen Gehsteig.

> Der obige Fall ist da durchaus ein gutes Beispiel: Weg 7718378 ist
> vorher getaggt gewesen als für Fußgänger verboten.

Geschenkt. Ist aber leicht zu korrigieren und kaum ein Grund zum
Komplettumbau.

> Selbst wenn man jetzt nur
> das "access"-Recht für Fußgänger umgesetzt hätte, wäre überhaupt nicht
> klar, wo da die Fahrradfahrer durchmüssen: [...]
> Das kann man in einem komplexen
> Lane-Tagging umsetzen, das 80% aller Mapper dann erst einmal
> interpretieren müssten

Du meinst das Lane-Tagging über Tags am Way? Das sich im Alltag längst
etabliert und gegenüber Ways-für-Spuren durchgesetzt hat? Ja, genau
dieses Schema solltet ihr verwenden.

Es gibt dort übrigens weder Busspuren noch Busbuchten noch überhaupt
markierte Spuren. D.h. die Straße mit sidewalk=both reicht völlig.

>> * Gleiches auf den Bahnsteigen (http://osm.org/way/367435362). Imho
>> gehören da keine Fußwege hin. Ein Router sollte schon selbst erkennen
>> können, dass die ganze Bahnsteiglänge für's Einsteigen gedacht ist.
> 
> Das Modell stammt gar nicht von uns, sondern hat sich schon seit langer
> Zeit etabliert

Ich verfolge durchaus selber die Tagging-Diskussionen im Projekt, und
kann von daher mit ziemlicher Sicherheit sagen: Nein, das ist nicht
"etabliert". Und außerhalb von Mailinglisten habe ich es bisher
ausschließlich an von euch gemappten Bahnsteigen gesehen.

> man mappt die Blindenleitstreifen als Fußwege.

Ich glaube das lasse ich mal für sich stehen.

> Generell: Wie wollen wir sonst mit vertikalen Strukturen umgehen? Für
> einen Laien dürfte eine Gliederung in Ebenen der intuitivste Zugang
> sein,

Wie wäre layer für outdoor, level für Indoor...?

> Für die Betreuung unserer Hiwis nehme ich folgende Erkenntnisse mit:
[...]
> Bitte ergänzt die Liste, falls ich etwas vergessen habe.

- Insbesondere die zuoberst genannten nicht Passau-spezifischen Fehler
bei den bisher bearbeiteten Bahnhöfen beheben und in Zukunft nicht mehr
machen.

Danke fürs Zuhören und viele Grüße,
Tobias

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

Re: [OSM-talk] The Proposed Great Colour Shift

[Tobias Knerr]

On 20.08.2015 10:09, Christoph Hormann wrote
 If you think a different styling than what is currently proposed would 
 be better it would be best to show it.

It's hardly fair to expect critics of the suggested new style to easily
come up with alternatives. For one, the effort in question was enabled
by sponsorship by Google, and took place over several months. This is
not easily duplicated by those favouring other ideas.

But more importantly, it discounts all those voices who favour the
status quo. Personally, I think that the problems with the current style
are relatively minor, and don't automatically justify a drastic change.

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

Re: [Talk-at] Adressdaten BEV

[Tobias Knerr]

Am 20.07.2015 15:07, schrieb Thomas Rupprecht:
 Wie es aussieht hat das BEV jetzt auch die Adressdaten für Österreich
 veröffentlicht. Ich bin noch im Kontakt mit dem BEV ob wir eine exlusiv
 Nutzung bzw doppel Lizenzierung mit ODbL für die Verwaltungsgrenzen und
 Adressdaten bekommen.

Wenn irgendwie möglich würde ich darum bitten, keine Daten unter ODbL zu
importieren. Das bringt nur diverse Probleme mit sich, u.a. bei
zukünftigen Anpassungen unserer eigenen Lizenz.

Eine Institution, die Daten unter ODbL veröffentlichen würde, lässt sich
womöglich auch auf andere Regelungen ein, z.B.:
* Namensnennung durch OSM, aber nicht bei unseren Datennutzern
* einfach ein darf für OSM verwendet werden, ohne Einschränkung auf
eine Lizenz

Viele Grüße,
Tobias

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

Re: [Talk-de] OSM Wiki-Übersetzung Griechisch?

[Tobias Knerr]

Am 15.07.2015 23:16, schrieb rza31:
 Hallo,
 bei https://wiki.openstreetmap.org/wiki/Wiki_Translation ist unter
 Andere Sprachen Griechisch nicht aufgeführt. Sollte man dies nicht
 ergänzen?

Ein roter Link für Griechisch (Ελληνικά) ist dort doch vorhanden? Oder
meinst du, dass jemand eine Übersetzung ins Griechische erstellen soll?


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

Re: [OSM-talk] 3D help needed

[Tobias Knerr]

Hi,

On 06.07.2015 00:29, Jóhannes Birgir Jensson wrote:
 I'm in touch with a person that added many buildings in Iceland as 3D
 models in Google Earth some years ago. You can find many of them there
 if you type in Kvosin into Google Earth - they look really good.

that would be a valuable contribution, so thank you for putting effort
into helping them.

Providing a possibility to upload freely-licensed 3D models for use with
OSM has long been a goal of various people in the 3D community. A 2014
birds of a feather meeting regarding this topic hasn't resulted in
anything tangible yet, unfortunately. I had also proposed the
development of such a platform as a Google Summer of Code project this
year, but that didn't work out.

As you said, OpenBuildingModels is theoretically a platform for models
like these. However, there has been very little activity since its
release a few years ago.

Recently, OSM Buildings has also started to use 3D models in their
visualizations.¹ I'm not sure if these models are freely available for
other OSM-based projects, though.

Nevertheless, we should try to find a quick solution here. If nothing
else works, I would at least advocate to publish the models under an
open license in some universal format like Collada somewhere, and to
start working on integrating these in our various applications. I would
be willing to offer some webspace for that, too.

Cheers,
Tobias

¹
http://blog.osmbuildings.org/2015/05/product-designer-rene-schulz-supporting.html

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

Re: [OSM-talk] Layers and landuse

[Tobias Knerr]

On 27.06.2015 11:19, michael spreng wrote:
 This is not a tagging error.

It is an error. Only the underground part of the ditch should have
layer=-1, and it needs to also have a tunnel tag.

As for landuse, such areas are typically non-physical, and as such not
easily inserted into the layer hierarchy. However, mappers are using
landuse far beyond its original definition, and also map physical things
such as pastures and (arguably) fields with it. At that point, the usual
layer rules need to apply.


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

Re: [OSM-talk] Mappers and apps should focus on relations at the very start

[Tobias Knerr]

On 27.06.2015 18:58, Fernando Trebien wrote:
 When this notion of grouping is
 presented at the very beginning, I believe people will easily
 understand it for all of the advanced scenarios

The notion of grouping would at least be more intuitive the common
relationship between things, which is very remote from how relations
are often used. Still, it isn't really a natural fit for some relation
types, e.g. building, bridge, tunnel, ... relations.

So if we are discussing to re-frame relations in a more understandable
fashion, I wonder if we shouldn't turn relations into *objects*.

From the current OSM environment, it seems clear that preset-based user
interfaces are popular. Mappers tend to grasp the concept of creating
an object, then adding more information to it quite easily. So what if
we base the data model around this?

Imagine mapping a building. Currently, there is a stark contrast between
the outline and the height of the building: One is a tag, and the other
is a way, i.e. geometry. Values can be many things - text, distances,
speed limits - but they cannot be geometry.

If the building was an object, then both the height and the outline
could be added as values of tags. Naturally, there could also be
multiple keys with geometry values, resulting in the same expressive
power as our relations - but in a much less scary wrapping.

Of course, behind the scenes this would still look like a relation with
tags and members. It's all in the presentation and ubiquity. I believe
(a hypothesis that would be interesting to test) that this would make
the more complex features of OSM significantly more accessible.

So should we target this for API 0.7? Not really. I'm under no illusion
that something like this could happen anytime soon. But imo it's an
fascinating idea to think about.

Tobias

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

Re: [Talk-de] waterway=riverbank

[Tobias Knerr]

Am 29.05.2015 06:25, schrieb Markus:
 Das würde ein weltweites Tagging-Schema zerstören...
 
 Wer weiss Genaueres?

Das geht auf ein erfolgreiches Proposal von 2011 zurück:
http://wiki.openstreetmap.org/wiki/Proposed_features/Water_details

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

Re: [Talk-at] Kleingartenvereine

[Tobias Knerr]

Am 14.05.2015 17:46, schrieb Wolfgang Schreiter:
 Dazu gibt es noch mehrere Beispiele, z.B. FF (Freiwillige Feuerwehr), VS
 (Volksschule), HS (Hauptschule). Es stellt sich grundsätzlich die Frage, ob
 solche Abkürzungen in Namen verwendet werden sollten.

Die Frage wird generell beantwortet mit: Nein, Abkürzungen in Namen
sollten vermieden werden. Steht jedenfalls seit langem so im Wiki.

Nun kann man bei extrem gängigen Abkürzungen noch über die
Sinnhaftigkeit streiten (z.B. Dr vs. Doktor), aber bei den hier
diskutierten Beispielen würde ich mich klar an die Regel halten.

Es ist generell für Software wesentlich einfacher einen Begriff
abzukürzen als den Begriff aus einer Abkürzung zu rekonstruieren. HS
beispielsweise wird ja auch für Hochschule, High School und Haltestelle
verwendet.

Ich wäre daher für die Verwendung der ausgeschriebenen Form, plus
short_name mit der Abkürzung. Damit ist dann auch die Suche nach dem
ausgeschriebenen Kleingartenverein erfolgreich, was momentan nicht der
Fall ist.

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

Re: [OSM-talk] Problems with the wiki (was Why OSM and not another collaborative mapping service?)

[Tobias Knerr]

On 09.05.2015 10:08, Christoph Hormann wrote:
 The problem is not exclusively Xxzme's attitude but also the combination 
 with the dominance of his/her/their edits due to the large amount of 
 energy and time spent.

I fully agree with that. Xxzme is not the first wiki user who has tried
to push through unpopular edits or who has engaged in edit wars, but
they are doing so at an unprecedented scale.

For a long time, I have tried to encourage them to improve their
behaviour, to give reasons for their changes, to respond to criticism,
to take care not to break links and to seek feedback before engaging in
huge edits across the wiki, but it simply doesn't work. Following their
own vision of cleaning up the wiki seems to trump everything else.

Considering the countless hours spent on dealing with them, and the loss
of valuable wiki contributors, their presence on the wiki is a net
negative. Unfortunately, the warning shot (i.e. the 1 month ban) didn't
really improve the situation, except giving everyone else a much-needed
breather.

Tobias

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

Re: [Talk-de] unpraktisches Nominatim-Ergebnis

[Tobias Knerr]

Am 02.05.2015 21:43, schrieb Christian H. Bruhn:
 Ich habe gestern auf openstreetmap.org nach Wildpark Eekholt
 gesucht. Da gab es mehrere Suchergebnisse. Das erste war
 http://www.openstreetmap.org/node/2414231380 , welches ein
 Straßenschild ist. So eine braune Tafel, welche an Autobahnen auf
 touristische Ziele hinweist.

Es ist ja auch fraglich, ob Wildpark Eekholt wirklich der Name des
Schildes ist. Ich würde da ja eher zu inscription (Beschriftung) tendieren.

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

Re: [Talk-at] Tagging der abgeholzten Waldflächen

[Tobias Knerr]

Am 26.04.2015 17:09, schrieb Stefan Tauner:
 Ja, das folgt aus der Definition von landuse=forest, denn dieses
 Tagging bezeichnet ganz allgemein wirtschaftlich genutzte
 Waldgebiete... was auch abgeholzte Flächen miteinschließt.

Das stimmt so nicht (mehr). Früher stand landuse=forest tatsächlich für
die forstwirtschaftliche Nutzung, aber inzwischen heißt es einfach nur
noch Wald - mit allen daran hängenden Assoziationen. Die entsprechende
Änderung wurde vor Jahren durchgedrückt (Wieso taggen wir die Wälder
denn zweimal als Wald?!?) und mit großflächigen Edits zementiert.

 Das Problem  dabei ist, dass die Renderer das als dunkelgrüne Fläche 
 darstellen und
 wir das alle mit Wald gleichsetzen

Das hängt aber damit zusammen, dass sich die Bedeutung des Tags
mittlerweile verändert hat. Wenn man die Situation wirklich bereinigen
will, dann muss man sich m.E. ein neues Tag suchen (landuse=forestry
oder so) und das dann konsequent dokumentieren und nutzen. Sonst wird
das Chaos nur noch größer.

Viele Grüße,
Tobias

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

Re: [OSM-talk] Sidewalks

[Tobias Knerr]

On 25.04.2015 11:29, wrote Roland Olbricht:
 A sidewalk (or bike lane) shall be mapped as a separate way only if a
 pedestrian cannot cross the car lanes at any point, i.e. there are
 fences or grass strip between footway and the car lanes.

Uh, the example in the other thread was a fence. Grass strips are easily
crossable for most pedestrians.

Given the number of problems that arise from separately mapping
sidewalks, we should only do it if strictly necessary. That is not the
case with most grass strips, especially narrow ones of uniform length.


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

Re: [OSM-talk] Proposal - automate rendering examples on OSM wiki

[Tobias Knerr]

On 20.03.2015 22:19, Jochen Topf wrote:
 I think the important part is doing the rendering, deciding on zoom levels and
 all this. This is going to be some work and will need some time.

Wouldn't it make sense to leave that responsibility to the projects,
similar to the decentralized generation of files consumed by Taginfo for
the projects feature? If a project team wants the added exposure via the
wiki, they will put in the effort to do some automation.

By the way, I'm in favour of allowing all OSM-based renderings to be
featured, not just the default style. People already obsess too much
about what is or isn't rendered by the default style imo.

 As
 a first step I suggest you look at 
 https://wiki.openstreetmap.org/wiki/Taginfo/Projects
 and see whether your rendering can be brought into taginfo that way.

Taginfo already allows including an url for an icon-sized image with
each tag. What do you think about allowing another optional url for a
larger image? That wouldn't be limited to node features and could be
used in the wiki for rendering examples.

Tobias

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

Re: [Talk-de] Taginfo-Challenge

[Tobias Knerr]

On 14.03.2015 13:59, Andreas Goss wrote:
 Da ich letztes mal noch keine Antwort bekommen hatte, wie sieht es mit
 case sensitive key aus?
 
 Spielt das für die Datenbank eine Rolle, also sollten alle key klein
 sein? Oder ist es egal, dann wäre es gut wenn Taginfo das da einfach
 ignoriert.

Die Konvention ist schon, dass Keys klein sind, siehe z.B. hier:
http://wiki.osm.org/Any_tags_you_like#Syntactic_conventions_for_new_tags

Viele Programme behandeln sie auch case sensitive, also ist es imo
sinnvoll, Großschreibungen von Keys zu korrigieren.

Die Ausnahme ist natürlich dort, wo sich in Einzelfällen etwas anderes
etabliert hat. Beispielsweise ist die Schreibweise TODO statt todo
heutzutage zwar nicht mehr populär, aber doch noch existent.


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

Re: [OSM-talk] Mechanically Cleaning Up FIXME Tags

[Tobias Knerr]

On 25.02.2015 02:58, Bryce Nesbitt wrote:
 It is apparent that a number of imports have left tens of thousands of
 fixme notes that have a low chance of ever getting addressed.  Pick your
 favorite from the lists above: set␣better␣denotation is my mine.

That's from a mechanical edit that should never have happened in the
first place. The edit was basically done in order to establish the
denotation tag for trees, which was almost nonexistent before.

The denotation values were not pulled from an external source, but based
on guesses of the kind another tree within x meters = must be a
cluster of trees. In my opinion, it could make sense to also remove the
denotation keys on trees with set␣better␣denotation. After all, the
continuing existence of that fixme shows that no human ever verified these.

I also agree with the general goal to get rid of pointless fixme values.

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

Re: [OSM-legal-talk] Travel Channel + OSM

[Tobias Knerr]

On 25.02.2015 09:51, Simon Poole wrote:
 http://osmfoundation.org/wiki/License#How_should_I_attribute_you.3F
 covers video, as outlined there they don't have to show attribution on
 screen the whole time, doing something when a/the map is first
 shown would likely be enough.

Who is behind these unnecessarily restrictive rules about attribution
popping up everywhere? It used to be that we simply had that general
rule that we wanted attribution reasonable to the medium, which would
definitely allow placing attribution into the credits for a video.

In my opinion, demanding anything more than a mention in the credits
is excessive, considering how many other people and organizations only
ever appear there. Of course it would be nice to get more, and we
should ask for it. But it should not be a hard rule.

Tobias

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

Re: [Talk-de] heise berichtet ueber osm.org-Routing integration

[Tobias Knerr]

Am 18.02.2015 12:09, schrieb Alexander Lehner:
 ... wenngleich auch etwas kritisch:

... und nicht ganz richtig: anonyme Korrekturen oder Hinweise
akzeptiert OpenStreetMap nicht.

Trotzdem sehr schön, dass uns das neue Routing-Feature ordentlich
Aufmerksamkeit bringt. Sind schon etliche Artikel aufgetaucht:

http://wiki.openstreetmap.org/wiki/OpenStreetMap_in_the_media

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

Re: [Talk-de] Update of german Aral petrol stations

[Tobias Knerr]

Am 12.02.2015 14:41, schrieb Sven Geggus:
 Wie bitte? Wenn es dieses Problem wirklich gäbe, dann hätten es alle Daten,
 die derzeit in der Datenbank sind ebenfalls, denn auch bei diesen Daten ist
 eine Re-Lizensierung nicht möglich.

Bei allen von Hand eingetragenen Daten hat der Urheber (= der Mapper)
die Contributor Terms akzeptiert. In denen steht drin, dass die Daten,
eine erfolgreiche Abstimmung vorausgesetzt, auch unter einer anderen
freien Lizenz veröffentlicht werden dürfen.

Bei Importen besteht das Problem, dass der eintragende Mapper nicht der
Urheber ist, und wir daher auch nicht automatisch die Zustimmung des
Urhebers zur Veröffentlichung unter anderen freien Lizenzen haben. Das
lässt sich lösen, indem der Urheber die Daten generell für die
Verwendung bei OSM (ohne Einschränkung auf eine bestimmte Lizenz) zulässt.

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

Re: [Talk-de] Update of german Aral petrol stations

[Tobias Knerr]

Am 11.02.2015 18:28, schrieb Michael Reichert:
 Ich persönlich denke, dass die ODbL als Lizenz für eine Import nicht
 ausreichend ist. Was passiert, wenn sich die Zweidrittelmehrheit der
 aktiven Mapper nach Artikel 3 der Contributor Terms für eine neue Lizenz
 entscheidet?
 http://www.osmfoundation.org/wiki/License/Contributor_Terms

+1

Auch ich bin der Ansicht, dass Daten nur dann importiert werden sollten,
wenn sie uns nach einem Lizenzwechsel noch erhalten bleiben. Das ist bei
Daten, deren Verwendung nur unter ODbL erlaubt ist, nicht der Fall.

Vielleicht lässt sich ja eine Lösung finden, die generell die Nutzung
für OSM (unabhängig von der Lizenz) erlaubt.

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

Re: [Talk-de] mehrere Häuser mit gemeinsamen Dach

[Tobias Knerr]

Am 03.02.2015 23:49, schrieb Holger Jeromin:
 Jetzt habe ich doch noch roof:shape=side_hipped [1] entdeckt. Scheint
 für einfachere Fälle zu funktionieren.

 Oder eine Linie als  roof:ridge quer rüber eintragen.

Es müssten 3 Linien mit gemeinsamen Knoten mit den Gebäuderändern sein.
Gemeinsame Firstlinien für mehrere Gebäude sind meines Wissens nirgends
definiert. Übrigens ist auch side_hipped keine standardisierte Dachform
(wobei man argumentieren könnte, dass entweder ein neuer roof:shape-Wert
oder ein Subtag für das normale hipped für so etwas sinnvoll wäre).

Viele Grüße,
Tobias

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

Re: [Talk-de] cycleway=track bei Bordstein Trennung

[Tobias Knerr]

Am 16.12.2014 13:05, schrieb Wolfgang Hinsch:
 Damit der Renderer erkennen kann, dass die extra-Fußwege an die Straße 
 gehören 
 und er sich somit die (für den Maßstab) passendere Variante aussuchen kann, 
 sollten es eine street-Relation geben, in der alle Linien, die zur gleichen 
 Straße gehören, erfasst sind. Das erleichtert auch die Zuordung von 
 Straßennamen etc. zu separaten Wegen.

Es erleichtert das Problem mit den Straßennamen. Aber das Kernproblem,
das ein Renderer-Autor hat, ist doch die Zuordnung eines Fußweges zu
einem ganz bestimmten Way, nicht einer Gruppe von Ways. Es kann ja sein,
dass manche Teile einer Straße einen Fußweg haben, andere vielleicht
zwei oder gar keinen.

Gruß,
Tobias

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

Re: [Talk-de] Abbiegespuren mit Fahrradspur

[Tobias Knerr]

Am 07.12.2014 19:19, schrieb Martin Vonwald:
 * Können auch Parkspuren und Gehsteige in die lane-Liste eingebaut
 werden? Wenn ja, wie?
 
 Parkspuren theoretisch ja, auch wenn ich kein Freund davon bin. Gehsteige
 würde ich nein sagen, da es ja keine Spuren für irgendwas sind. Bei
 Gehsteigen würde ich bei dem bewährten Konzept mit den sidewalk-Tags (inkl.
 Sub-Tags und ohne separate Wege) bleiben.

Momentan haben wir Tags für die normalen lanes, für die cycleways, für
die parking:lanes, und für die sidewalks. Das Problem, das ich lösen
will: Wie kann ich angeben, in welcher Ordnung die sich zueinander
befinden?

Ich kann mir da zwei Lösungen vorstellen:
* Alles in die *:lanes=* mit integrieren
* Zusätzlich zu den genannten Tags noch eine Liste taggen, die die
Reihenfolge der genannten Elemente angibt

Und ich versuche gerade, etwas nachzufühlen, was wohl besser ankommt.

 * Zumindest, so lange es nicht ausdrücklich definiert ist, halte ich es
 nicht für selbstverständlich, dass die access-Angaben Auswirkungen auf
 die Breite etc. haben. Radspuren sind ja nicht dasselbe wie eine Spur
 mit voller Breite, die für Radfahrer ist (leider ;-)). Siehst du das
 anders?
 
 Jeder der mit xxx:lanes-Tags arbeitet, sollte sich vorstellen, dass er nur
 die eine Spur sieht und gedanklich alle andere ausblenden und alle
 xxx:lanes-Tags zu xxx reduzieren. In deinem Beispiel bleibt dann ein Weg
 übrig, welcher nur für Radfahrer zulässig ist. Welche Breite würdest du
 annehmen für einen Weg, welcher nur für Radfahrer erlaubt ist?

Ich würde normal gar nicht auf die access-Tags sehen, wenn ich die
Breite eines Weges bestimme, sondern nur auf den highway-Wert und width.
Das funktioniert auch bei normalen Wegen gut genug, aber bei den Spuren
lande ich so eben auch bei Radspuren bei der Standardbreite normaler Spuren.

Das will ich jetzt nicht zum prinzipiellen Problem aufbauschen, nur
fände ich es gut, wenn man das klarstellen könnte.

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

Re: [Talk-de] Abbiegespuren mit Fahrradspur

[Tobias Knerr]

Am 05.12.2014 13:19, schrieb Martin Vonwald:
 Vom Prinzip her ist bicycle:lanes=...|designated|... und
 cycleway:lanes=|lane| identisch. Welche Variante besser ist, kann
 ich sagen. Ich tendiere eher zu bicycle:lanes, da es konsistent mit der
 Angabe anderer access-Beschränkungen wäre, z.B. bus:lanes.

Ich sehe hier einige Probleme:
* Im Sinne unserer damaligen Diskussion, ob left/right nicht besser wäre
als forward/backward: Wie mappe ich Radwege, die in beide Richtungen
nutzbar sind?
* Können auch Parkspuren und Gehsteige in die lane-Liste eingebaut
werden? Wenn ja, wie?
* Zumindest, so lange es nicht ausdrücklich definiert ist, halte ich es
nicht für selbstverständlich, dass die access-Angaben Auswirkungen auf
die Breite etc. haben. Radspuren sind ja nicht dasselbe wie eine Spur
mit voller Breite, die für Radfahrer ist (leider ;-)). Siehst du das anders?

Gruß,
Tobias

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