Re: [OSM-talk] mapilio? (street-level imagery)

[Simon Poole]

Am 31.05.2023 um 22:08 schrieb Christian Quest:


... OSM editors integration.


That was one of the reasons why I was asking, as I have already done 
some work on a STAC layer based on the GeoVisio API.


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

Re: [OSM-talk] mapilio? (street-level imagery)

[Simon Poole]

Christian, does this relate in some fashion to Geovisio?

And a, I suppose, obvious observation: key for adoption in OSM would be 
an easy to access API for editing apps. Does that exist/are there plans 
for one?


Simon

Am 30.05.2023 um 16:01 schrieb Christian Quest:

Le 24/05/2023 à 14:31, Greg Troxel a écrit :

I just got spam from mapilio, implying that I was a "Mapilio
contributor".  This was, to my memory, the first I had heard of them.


I have avoided most street-level imagery schemes as not being
structurally similar to OSM (open source tooling, community project and
licensing scheme).



I'm not answering directly to your post, but I think you may like my 
answer ;)



I'm currently working on the Panoramax project, co-originated by 
OpenStreetMap France and IGN (Institut Géographique National).


In the very near future, we should have a street-level imagery offer 
that matches:


- open source tooling

- community project

- (real) open licensing scheme

as well as...

- decrentralized / federated solution... to avoid having one more time 
a single point of failure with an actor hosting all the pictures !


We have not communicated much so far except in France on 
https://panoramax.fr/ as we're still working on the MVP.





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

Re: [OSM-talk] mapboox improve the (proprietary database used as en overlay) map

[Simon Poole]

Am 12.04.2023 um 16:20 schrieb Mateusz Konieczny via talk:
From legal point of view it depends on specifics, but yes it can be 
legal to

render using odbl+proprietary data.

See 
https://wiki.osmfoundation.org/wiki/Licence/Community_Guidelines/Horizontal_Map_Layers_-_Guideline


It should be noted that this guideline follows from the concept of 
Collective Databases in the ODbL and in general of the idea of works 
that can have multiple independent constituent parts. If what Mapbox is 
doing is consistent with the licence naturally depends on the specifics 
as Mateusz write, Marc, do you have a link to the discussion in question?


Simon



Warning: I am not a lawyer.


Apr 7, 2023, 14:21 by marc_m...@mailo.com:

Hello,

following a discussion on the mailing list talk-fr,
mapbox "improve the map" now feeds their proprietary database,
the one that is displayed on top of the osm

is it acceptable in terms of licensing to render using
odbl+proprietary data?

ethically it's obviously very bad to appropriate user contributions
in this way, does anyone have a contact at their end to try and get
them to return to more ethical behaviour?
on talk-fr, no one from mapbox has replied since this behaviour
was pointed out

Regards,
Marc



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



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


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

Re: [OSM-talk] Extending the 'geo:' uri scheme: Adding parameter 'osmid'

[Simon Poole]

Not quite unexpected this discussion has already gone off on a tangent 
about stable ids. My question on the other hand would be: what do you 
actually want to achieve and what would you expect an application to do 
with the parameter?


It should be noted that we already have a couple of URI schemes in use 
for OSM based tools/editors, and naturally the website object/element 
browsing support.


Simon

Am 02.01.2023 um 18:57 schrieb Sören Reinecke:


Hey,

It came into my mind to get IETF to standardize a parameter explicitly 
linking to osm objects with their corresponding type and id.


The 'geo' URI scheme is standardized as RFC 5870 
<https://www.rfc-editor.org/rfc/rfc5870> with examples of usage 
<https://www.rfc-editor.org/rfc/rfc5870#section-6>. It allows us to 
link to geospatial ressources from web pages or applications 
supporting URI schemes in general. It allows (web) developers to 
direct their users to their map browser of use e.g, Organic Maps, 
Google Maps, Apple Maps, ... The official osm.org makes use of this 
specification in the "share" feature already. Currently it only 
supports linking to geospatial ressources by their coordinates and not 
some id. As OpenStreetMap is playing an important part in the 
geospatial world, the OSMF should try to get IETF convinced.


See registered URI parameters in the 'geo' URI scheme:
'geo' URI Parameters registry at IANA.org 
<https://www.iana.org/assignments/geo-uri-parameters/geo-uri-parameters.xhtml>


Our own parameter could have the following syntax:

osmid=(N|W|R)


What do you think?

Greetings

Sören Reinecke


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


OpenPGP_signature
Description: OpenPGP digital signature
___
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)

[Simon Poole]

Am 30.11.2022 um 18:50 schrieb Minh Nguyen:

..
The contributor terms in question state:

This Agreement shall be governed by English law without regard to 
principles of conflict of law.
[1] 
https://wiki.osmfoundation.org/wiki/Special:PermanentLink/9165#Miscellaneous


My understanding of what the board wants is simply that the terms that 
we get to utilize 3rd party data under do not conflict with the 
contributor terms, that is something very different than asking a 3rd 
party source to agree to the contributor terms. Definitely the OSMF is 
free to, negotiate terms that do not specify English law.


Simon

PS: note on the side: the ODbL doesn't specify EN law.



OpenPGP_signature
Description: OpenPGP digital signature
___
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)

[Simon Poole]

Am 29.11.2022 um 15:30 schrieb Greg Troxel:

...
Also, what we need is a copyright license, so that's not necessarily --
and hopefully isn't -- a contract.
Well there is this kind of underlying assumption that for most material 
in question, with the exception of actual maps, there is no copyright 
protection in the US and we are talking about contractual arrangements 
(I'm not going to dive in to the aspect that different jurisdictions 
have different implementations of how this all works, but see for 
example https://lwn.net/Articles/747563/). This is in any case just my 
take and the OSMF might have a completely different position for 
tactical reasons.

   It seems obvious that asking a US
entity to enter into a contract under foreign law (and the same is
almost certainly true for any government entity in any other
jurisdiction) is just not going to fly.


You are assuming that the OSMF would require UK law, which might or 
might not be the case.


Simon



OpenPGP_signature
Description: OpenPGP digital signature
___
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)

[Simon Poole]

Hi Tobias

That sounds better.

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 could naturally argue about how much the OSMF 
is committed to individual sources to keep the chain OSM attribution -> 
3rd party source attribution around, but that disruption is not worth it 
IMHO.


Simon

Am 29.11.2022 um 00:48 schrieb 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


OpenPGP_signature
Description: OpenPGP digital signature
___
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)

[Simon Poole]

Am 29.11.2022 um 03:57 schrieb Minh Nguyen:

Vào lúc 15:48 2022-11-28, Tobias Knerr đã viết:

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).


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? The wiki 
has a {{n/a}} template for this purpose.
I don't see a problem here,  PD works / data and CC0 licenced material 
do not restrict how you use them in any fashion so I don't see why any 
action would be required.


I've already heard concerns from a couple U.S. mappers about this 
thread, because the community here been operating under the assumption 
that public domain datasets are the best-case scenario for inclusion 
in OSM. If a local government agency has already released something 
into the public domain, irrevocably and so forth, it would be 
counterproductive to send their legal department a scary-looking 
document to fill out. I don't know how I'd convince them that they 
have the legal authority to enter into an agreement governed by 
English law. Hopefully I'm overreacting.






OpenPGP_signature
Description: OpenPGP digital signature
___
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)

[Simon Poole]

Am 28.11.2022 um 20:11 schrieb Amanda McCann:

Hello fellow OSMers.

As you are no doubt aware, OSM requires that data imports be listed on the OSM 
Wiki ( https://wiki.openstreetmap.org/wiki/Import/Catalogue ), including if the 
source is “ODbL OK status”.

At the Nov. 2022 OSMF Board meeting (25 Nov), the Board voted that imports 
should, from now on, list whether the data source is compatibly (or 
incompatible) with the OSM Contributor Terms¹.


The board has obviously been reading too much Greek mythology (or maybe 
Batman) and has taken to speaking in riddles :-)


What is "OSM Contributor Terms compatibility" supposed to be? 
Sub-licenseable? Neither the ODbL nor any CC licence with exception of a 
CC0 waiver allow this. Compatible with the licence change provisions? As 
an absolute that is going to be very difficult as the only requirement 
is for a new licence to be "open". It would definitely exclude all 
share-alike licences including naturally the ODbL except if the target 
licence is compatible with the original licence. Has the LWG been asked 
for an opinion, list of compatible/incompatible licences? That's just 
what immediately comes to mind.


A further note "As you are no doubt aware, OSM requires that data 
imports be listed on the OSM Wiki" has never been a formal OSMF policy. 
Yes it would have always made sense to have stricter controls on imports 
in particular not only licence compatibility but proper documentation 
including contacts. But that was politically always untenable and that 
particular horse has long bolted.


Simon


The Board has also budgeted to commission a template that OSMers can use to 
request that data sources release their data under those terms. That will obv. 
follow later. However given that OSM is mostly volunteer run, I don't know 
if/when that will be ready for you.

The minutes of the meeting have not yet been written, nor accepted, but when 
they are (in about a month), you will find the specifics here): 
https://wiki.osmfoundation.org/wiki/Board/Minutes/2022-11

¹ https://wiki.openstreetmap.org/wiki/Open_Database_License/Contributor_Terms



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

Re: [OSM-talk] Use of "Proprietary" imagery to edit OSM

[Simon Poole]

Am 27.10.2022 um 06:17 schrieb Michael Collinson:
and note that Bing imagery is provided to us on the same basis - for 
use in OSM but not otherwise.


Mike


Bing imagery is available for inspection to everybody, for use in OSM 
terms are relaxed that would otherwise prohibit tracing etc.


Not comparable to not having access to the source at all, in this case 
we don't even know if the Lyft employee is referring to street level 
images (which might actually need processing before release), or 
aerial/sat imagery.


Simon



On 2022-10-27 00:08, Clifford Snow wrote:


On Wed, Oct 26, 2022 at 2:59 PM Mike Thompson  
wrote:


Concerning this changeset:
https://www.openstreetmap.org/changeset/128035436

Changeset comment:

added missing roads according to proprietary aerial imagery

Editing organization's follow on comment:
"Proprietary" for Lyft meaning "provided to us for use in OSM but
not the general public"

Is this acceptable?  In my mind it is not as the whole community
should have access in order to verify and build on these edits.

I look at it as if they were using local knowledge. For example, If I 
walk downtown and take pictures of business doors to capture address, 
name, and hours for use in updating OSM but don't upload those pics - 
I consider that acceptable.


For Lyft to make their imagery public they would have to insure that 
nothing private, such as faces, license plates, etc. I'm sure they 
don't want the added cost required make them public.


Clifford

--
@osm_washington
www.snowandsnow.us <https://www.snowandsnow.us>
OpenStreetMap: Maps with a human touch

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



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


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

Re: [OSM-talk] Vespucci - Proximity Alerts - Not working

[Simon Poole]

Am 12. Oktober 2022 20:04:42 MESZ schrieb Mike Thompson :
>On Wed, Oct 12, 2022 at 11:42 AM Simon Poole  wrote:
>
...
>>
>Thanks.  Unfortunately most of the time I will be surveying without a data
>connection, so this isn't going to work for me.

I would recommend using an offline data source in such a scenario, see 
https://www.openstreetmap.org/user/SimonPoole/diary/193235

>> Simon
>>
>> PS: osm-talk is not a suitable forum for support questions.
>>
>Sorry, what do you recommend?

Our github repo, or help.openstreetmap.org (and sometime in future its 
replacement).

Simon
>
>Mike

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit Kaiten Mail gesendet.

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

Re: [OSM-talk] Vespucci - Proximity Alerts - Not working

[Simon Poole]

The alerts are generated when data is downloaded/merged and the device location 
is within the specified radius around the object causing the notification.

With other words you need to have one of the auto download options enabled for 
the mechanism to work (or you need to replace all the data).

Simon

PS: osm-talk is not a suitable forum for support questions.

Am 12. Oktober 2022 18:29:37 MESZ schrieb Mike Thompson :
>I am trying to get Vespucci to give me an audible alert when I travel to
>within a certain distance of a OSM map note, or a OSM object with a fixme
>tag.  I have not been able to get this feature to work, at least not in the
>manner that I would like it to work.  It does alert when I initially
>download OSM data for any notes etc. that are near my location at that
>time.  This is expected.  However, when I then travel to another location
>within the download area with a note, etc., Vespucci does not produce an
>alert.
>
>* "Generate notifications" is turned on
>* "Max distance for notifications" is 30 meters - under most conditions my
>phone's location should be more accurate than that.
>
>What am I doing wrong?
>
>Mike

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit Kaiten Mail gesendet.___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Making GPS tracks in Android

[Simon Poole]

Non-open apps will typically use googles play services fused location 
provider, which as the name implies doesn't just use GNSS data. For 
generating tracks it is unsuitable in any case so a pure tracker is 
unlikely going to use it.


Simon

Am 21.12.2020 um 01:02 schrieb Alan Mackie:
I have noticed that Google Maps somehow seems to get a location at 
times when all other apps are struggling.


I'm not entirely convinced the playing field is level there.

On Sun, 20 Dec 2020, 18:18 Simon Poole, <mailto:si...@poole.ch>> wrote:


I don't expect side loading to be a thing for very much longer.
Given googles crack down on anything using location, see
https://twitter.com/vespucci_editor/status/1331541328883298306
<https://twitter.com/vespucci_editor/status/1331541328883298306>
for some of the drama, it would seem to be silly to leave that
avenue open. Definitely you are going to run in to problems as
soon as you start building against more recent SDK.

Simon

Am 20.12.2020 um 20:28 schrieb ipswichmapper--- via talk:

In this case simply use Fdroid. Its not hard and the apps on
there give you peace of mind.

--


20 Dec 2020, 19:14 by talk@openstreetmap.org
<mailto:talk@openstreetmap.org>:

Gps logger was perfect, unfortunately :
https://github.com/mendhak/gpslogger/issues/849
<https://github.com/mendhak/gpslogger/issues/849>
Yves

Le 20 décembre 2020 19:43:00 GMT+01:00, Martijn van Exel
 <mailto:m...@rtijn.org> a écrit :

Andy,

If you would like something lightweight that just does
GPS track recording, I would recommend GPS Logger
https://wiki.openstreetmap.org/wiki/GPS_Logger_for_Android
<https://wiki.openstreetmap.org/wiki/GPS_Logger_for_Android> .
A nice bonus is that you can have the app automatically
upload your tracks to OSM in whatever privacy mode you
choose. It can also sync with Nextcloud, Dropbox etc.

OSMTracker offers a little more functionality like
recording waypoints with specific, configurable notes,
and recording audio notes.
https://wiki.openstreetmap.org/wiki/OSMTracker_(Android)
<https://wiki.openstreetmap.org/wiki/OSMTracker_(Android)>

I’m not on Android right now but I’ve used both these OSS
apps for years.

Martijn


On Dec 20, 2020, at 5:36 AM, Andy Mabbett
mailto:a...@pigsonthewing.org.uk>> wrote:

Father Christmas came early this year, and has delivered
to me a smart
new Android phone, whose GPS is much better than on my
old one.

I want to use it to trace some tracks on a local nature
reserve. What
app(s) do you recommend for this?

-- 
Andy Mabbett

@pigsonthewing
http://pigsonthewing.org.uk <http://pigsonthewing.org.uk>

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




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

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



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

Re: [OSM-talk] Making GPS tracks in Android

[Simon Poole]

I don't expect side loading to be a thing for very much longer. Given 
googles crack down on anything using location, see 
https://twitter.com/vespucci_editor/status/1331541328883298306 for some 
of the drama, it would seem to be silly to leave that avenue open. 
Definitely you are going to run in to problems as soon as you start 
building against more recent SDK.


Simon

Am 20.12.2020 um 20:28 schrieb ipswichmapper--- via talk:
In this case simply use Fdroid. Its not hard and the apps on there 
give you peace of mind.


--


20 Dec 2020, 19:14 by talk@openstreetmap.org:

Gps logger was perfect, unfortunately :
https://github.com/mendhak/gpslogger/issues/849
<https://github.com/mendhak/gpslogger/issues/849>
Yves

Le 20 décembre 2020 19:43:00 GMT+01:00, Martijn van Exel
 a écrit :

Andy,

If you would like something lightweight that just does GPS
track recording, I would recommend GPS Logger
https://wiki.openstreetmap.org/wiki/GPS_Logger_for_Android
<https://wiki.openstreetmap.org/wiki/GPS_Logger_for_Android> .
A nice bonus is that you can have the app automatically upload
your tracks to OSM in whatever privacy mode you choose. It can
also sync with Nextcloud, Dropbox etc.

OSMTracker offers a little more functionality like recording
waypoints with specific, configurable notes, and recording
audio notes.
https://wiki.openstreetmap.org/wiki/OSMTracker_(Android)
<https://wiki.openstreetmap.org/wiki/OSMTracker_(Android)>

I’m not on Android right now but I’ve used both these OSS apps
for years.

Martijn


On Dec 20, 2020, at 5:36 AM, Andy Mabbett
mailto:a...@pigsonthewing.org.uk>> wrote:

Father Christmas came early this year, and has delivered to
me a smart
new Android phone, whose GPS is much better than on my old one.

I want to use it to trace some tracks on a local nature
reserve. What
app(s) do you recommend for this?

-- 
Andy Mabbett

@pigsonthewing
http://pigsonthewing.org.uk <http://pigsonthewing.org.uk>

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




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


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

Re: [OSM-talk] Please review "Community attribution advice” wiki page

[Simon Poole]

Am 08.12.2020 um 18:36 schrieb Rory McCann:

Yes, fundamentally, you're 100% correct. The ODbL licence is the thing that 
matters when it comes to what's legally required. And that says nothing about 
“device independent pixels” or “javascript popup clicks”, it only refers to the 
mental state of someone.

The Charter of Fundamental Rights of the European Union on data protection 
(Art. 8) is only about 80 words long  (DE 73, EN 82, GA 101), but the GDPR that 
implements it is 55,000 words long. I view the ODbL as like our “constitution” 
for what you can do with the data.


This analogy is clearly wrong. If anything at all, the contributor terms 
would be the constitution, the ODbL is just one of many possible ways 
the constitutional requirements could be implemented, and, if you so 
want, the guidance published by the OSMF are the ordinances that cover 
details and fix issues that the law makers didn't foresee or which are 
simply mistakes.



It will be short, but for practical real word answers you need laws & court cases 
which expand on it. One can always challenge a law for violating a constituation limit 
or requirement, and it should be the same with the ODbL & the OSMF's Attribution 
Guidelines.


But outside of the realm of not really fitting analogies, there is a 
reason why in many modern states the constitution and laws evolve, 
because the world and the circumstances in which the rules are applied 
change over time, and wise governing bodies adapt their rule book to 
changing reality. The ODbL was formulated as a generic database licence, 
independent of the subject matter and without the more than a decade 
experience with actual use cases that we have now, many of which were 
not considered at the time.


We can take a pragmatic approach to this, which was the practice over 
the last 10 years and undoubtably one of the reasons OSM has become such 
a thriving success, we can formally revise the law (one of the LWG 
proposals for getting out of the quagmire in a democratic fashion that 
wasn't responded to), or we can tie ourselves to yesteryears fights with 
overly literal reading of the rules without taking change in to account.


Naturally people tend to only be literal when it serves their specific 
political aims and allow them to maximize hubris and strife, and not 
when not. Maybe I should just be literal about the contributor terms and 
bring OSM to a screeching halt for effect.


Simon



So I think there's a lot of benefit in writing out, in my more detail, how you 
can follow §4.3, rather than speaking in generalities.

On Tue, 8 Dec 2020, at 00:08, Christoph Hormann wrote:



Rory McCann  hat am 07.12.2020 22:57 geschrieben:

But I think this attribution is too vague. It's advice seems to restate the 
relevant section from the ODbL. There are many examples of poor attribution 
where someone could argue that they meet this standard.

As i have already explained to you in

http://blog.imagico.de/the-osmf-changes-during-the-past-year-and-what-they-mean-for-the-coming-years-part-2/#comment-141145

the opposite is the case - the advise as formulated precisely explains
the criterion for valid attribution.

Attribution has the purpose to be perceived by humans.  To determine if
a certain form of attribution is acceptable you have to look at the
effect it has on human perception while interacting with the produced
work.

It is understandable that to people with a primarily technical
background this very concept appears uncomfortable and hard to grasp
and their reflex is to substitute this with something purely technical
where you can essentially program a test to verify if the attribution
is OK independent of the human user.  That cannot work.

--
Christoph Hormann
http://www.imagico.de/

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


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




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

Re: [OSM-talk] id Editor auto-converts split polygons into MP relation

[Simon Poole]

Am 30.10.2020 um 16:33 schrieb Dave F:



But anyway... Point slit stands: Why did iD take this authoritarian 
position.
Already pointed this out n-times now: because it synthesizes an area 
object type.



As has been noted other, editors don't make this assumption.


Other editors don't try to synthesize an area type.



A split polygon with only an outer MP is not an "area".


It is, you are really totally mistaken on this. Particularly if you are 
reusing ways that are parts of other MPs it is quite common to have an 
MP with a sole outer ring composed of multiple ways (aka a "split 
polygon"). That it is typically unnecessary in the case of a building 
doesn't make it invalid.


Simon





The correct solution to split polygons with tags on the ways is to 
rejoin those ways, not create a MP.



As I pointed out, the question is -when- to rejoin those ways.


As I pointed out, that's for the contributor to decide, not the editor.


 A MP with only one* outer is invalid.


Nope.


There's a clue in the name 'MultiPolygon' there has to be more than one.
Splitting into two serves no purpose, adds no quality. Entropy isn't 
beneficial for the OSM database.


Incomplete MP relations are not beneficial to OSM quality.

DaveF


OpenPGP_0x4721711092E282EA.asc
Description: application/pgp-keys


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

Re: [OSM-talk] id Editor auto-converts split polygons into MP relation

[Simon Poole]

Am 29.10.2020 um 00:17 schrieb Dave F:
iD editor attracts a hell of a lot of "WTFs", doesn't it? I mean, even 
its most ardent fan must occasionally raise a Roger Moore eyebrow.


bhuousel has taken the presumptive decision that the contributor's 
desired end result will always be a MP relation. This is wrong, plain 
& simple (& quite arrogant). iD editor should provide tools to allow 
contributors to make their own decisions as easily as possible & not 
take them on their behalf.


I'm not sure why you believe Bryan has or had anything to do with that 
specific design decision, but he didn't, that happened a substantial 
time before he had any formal involvement.



As has been noted other, editors don't make this assumption.


Other editors don't try to synthesize an area type.



The correct solution to split polygons with tags on the ways is to 
rejoin those ways, not create a MP.



As I pointed out, the question is -when- to rejoin those ways.

 A MP with only one* outer is invalid.


Nope.

* splitting it still means there's only one.

Relations were created to allow mapping of entities, not possible with 
just ways. They aren't meant to be the default for all objects.



See above.

Simon



DaveF

On 27/10/2020 08:11, Simon Poole wrote:
Its done that essentially since day one. As Bryce points out doing so 
keeps the object a valid "area" (and iD makes a valiant effort to 
stop you from breaking that).


It is also one of my favourite examples in talks why trying to keep 
things simple for the user is very difficult and some times 
counterproductive.


Lots of people have had the wtf moment when they come along a 
multi-polgon consisting of just one ring built from two ways. The 
problem is that once the user has split the polygon, there is no 
obvious point in time were you can be sure that the user is finished 
with it and you could simplify, particularly when you are trying to 
get the user to save often and early. So the simplification for the 
iD user comes at the expense of wtf's of everybody else.


Simon

Am 27.10.2020 um 02:05 schrieb Dave F via talk:

Hi

I don't use iD editor much, but I've just discovered it 
auto-converts closed polygons which are split (Shortcut Key = X) 
into MP relations.


I'm struggling to comprehend a logical reason for this. Is there 
one? If there's been a previous discussion which I've missed please 
post a link.


There's a couple of threads on iD's github issues, bhousel closed 
them with "wontfix - I Saw A Thing I Didn't Like (but is valid in OSM).


It may be valid, but is it desirable or helpful? I split closed 
ways, in P2, for various reasons without wanting them to be 
converted. How many newbies would even know what a MP relation is?


Having them as as split tagged ways is just as "valid". More so, 
considering splitting long ways is desirable.


DaveF




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


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




OpenPGP_0x4721711092E282EA.asc
Description: application/pgp-keys


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

Re: [OSM-talk] id Editor auto-converts split polygons into MP relation

[Simon Poole]

Its done that essentially since day one. As Bryce points out doing so 
keeps the object a valid "area" (and iD makes a valiant effort to stop 
you from breaking that).


It is also one of my favourite examples in talks why trying to keep 
things simple for the user is very difficult and some times 
counterproductive.


Lots of people have had the wtf moment when they come along a 
multi-polgon consisting of just one ring built from two ways. The 
problem is that once the user has split the polygon, there is no obvious 
point in time were you can be sure that the user is finished with it and 
you could simplify, particularly when you are trying to get the user to 
save often and early. So the simplification for the iD user comes at the 
expense of wtf's of everybody else.


Simon

Am 27.10.2020 um 02:05 schrieb Dave F via talk:

Hi

I don't use iD editor much, but I've just discovered it auto-converts 
closed polygons which are split (Shortcut Key = X) into MP relations.


I'm struggling to comprehend a logical reason for this. Is there one? 
If there's been a previous discussion which I've missed please post a 
link.


There's a couple of threads on iD's github issues, bhousel closed them 
with "wontfix - I Saw A Thing I Didn't Like (but is valid in OSM).


It may be valid, but is it desirable or helpful? I split closed ways, 
in P2, for various reasons without wanting them to be converted. How 
many newbies would even know what a MP relation is?


Having them as as split tagged ways is just as "valid". More so, 
considering splitting long ways is desirable.


DaveF




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


OpenPGP_0x4721711092E282EA.asc
Description: application/pgp-keys


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

Re: [OSM-talk] User deleting many roads in Brazil

[Simon Poole]

You need to take this up with the DWG (d...@osmfoundation.org) once 
direct contact with the mapper in question has failed. Posting to this 
and the tagging list is not going to achieve anything except that you 
will receive pointers to the DWG.


Simon

Am 24.10.2020 um 17:54 schrieb Erick de Oliveira Leal:
Good morning, a user in Brasil is deleting many roads, I think all of 
its changeset need to be reverted.

Examples of bad changesets:
https://www.openstreetmap.org/changeset/92345676 
<https://www.openstreetmap.org/changeset/92345676>
https://www.openstreetmap.org/changeset/ 
<https://www.openstreetmap.org/changeset/92345676>92703956 
<http://overpass-api.de/achavi/?changeset=92703956>
https://www.openstreetmap.org/changeset/ 
<https://www.openstreetmap.org/changeset/92345676>92610958 
<http://overpass-api.de/achavi/?changeset=92610958>


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


OpenPGP_0x4721711092E282EA.asc
Description: application/pgp-keys


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

Re: [OSM-talk] Doocracy | Re: Idea for improving mapping system

[Simon Poole]

Am 18.10.2020 um 16:49 schrieb Colin Smale:


On 2020-10-18 15:04, Simon Poole wrote:



Am 18.10.2020 um 11:07 schrieb Rory McCann:

Like mnany things in OSM, the reason it hasn't been done is because no-one has actually done it 
yet. It looks like other people find your idea of "levels" and "badges" 
interesting, so you should try attempt it yourself.


Like many things in OSM, the reason that it isn't being done, is 
because it has been tried and has failed. It looks like that other 
people don't find the idea of "levels" and "badges" interesting, so 
you shouldn't attempt it again.
...unless either the proposal, or the circumstances, have changed in 
some significant way, or unless a substantial period of time has 
passed. Never say never.


Agreed, but the point was that there is 16 years of OSM-history in which 
most stuff from the 5-minute (community) manager has been tried in one 
way or the other, and there are reasons, which might need to be 
re-evaluated if things have significantly changed, why things are not 
being done, -not- that they simply hasn't been tried.




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


OpenPGP_0x4721711092E282EA.asc
Description: application/pgp-keys


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

Re: [OSM-talk] Doocracy | Re: Idea for improving mapping system

[Simon Poole]

Am 18.10.2020 um 11:07 schrieb Rory McCann:

Like mnany things in OSM, the reason it hasn't been done is because no-one has actually done it 
yet. It looks like other people find your idea of "levels" and "badges" 
interesting, so you should try attempt it yourself.


Like many things in OSM, the reason that it isn't being done, is because 
it has been tried and has failed. It looks like that other people don't 
find the idea of "levels" and "badges" interesting, so you shouldn't 
attempt it again.




On Sun, 18 Oct 2020, at 4:31 AM, TheAdventurer64 wrote:

Hello everyone,

A user and I were talking about implementing a system for better
mapping, as described here:
https://osmus.slack.com/archives/C029HV951/p1602968516431900
This addition would have many benefits, including:
* More mapping. We have tons of new mappers each day, as well as a
great editor for them. However, many of these new mappers leave after
just a few edits. Examples:
https://www.openstreetmap.org/user/lukastheg03
https://www.openstreetmap.org/user/Th3Roomi3
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


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


OpenPGP_0x4721711092E282EA.asc
Description: application/pgp-keys


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

Re: [OSM-talk] Face and license blurring (GDPR territories)

[Simon Poole]

Am 07.10.2020 um 10:25 schrieb Christian Quest:


We have tested blurring using image segmentation which allows to blur 
full parts of pictures like people and cars, not only faces and 
license plates.



Here is the result: https://takeitout.cquest.org/photo/cquest/blurred/


The code used is on github: https://github.com/tyndare/blur-persons/


We did some tests using TPU to speedup the process.


That looks (IMHO) very good and addresses some of the concerns I pointed 
out, naturally not perfect, but it is far better than simply blurring 
faces and number plates. As a tendency I would remove any colour of the 
blurred object too in particular to make cars even less identifiable.


Simon

PS: why handbags are important for OSM is a bit of a mystery though :-)



OpenPGP_0x4721711092E282EA.asc
Description: application/pgp-keys


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

Re: [OSM-talk] Face and license blurring (GDPR territories)

[Simon Poole]

Am 07.10.2020 um 01:13 schrieb Niels Elgaard Larsen:

...
You will probably have to let users add and remove blurs.
That is what Mapillary do.

They do not, they stopped providing that facility literally years ago, 
and they've gone as far as no longer storing unblurred images even for a 
limited time now.


The other important point to understand is that there is no reason to 
believe that face and licence plate blurring is sufficient to avoid 
trouble in countries with strict data protection regulation as long as 
people and vehicles can be identified and behaviour associated with 
individuals can be deduced from the images (with other words blurring 
would have to be far more complete to be on the safe side). There is 
simply no case law, because there have been, afaik, no cases that have 
actually gone to court.


tl;dr version you need to make your own risk assessment (and ask your 
own counsel).


Simon



OpenPGP_0x4721711092E282EA.asc
Description: application/pgp-keys


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

Re: [OSM-talk] Cannot find address ringvegen 45 Sørkjosen in nominatim

[Simon Poole]

Nominatim tries to build correct address hierarchies from the data, in
particular it suspects a matching street (name) in the vicinity if an
addr:street tag is specified. While it will match a wide range on name
tags on streets (see
https://github.com/osm-search/Nominatim/blob/master/settings/import-address.style),
if none match it is not going to work.

Given that this is in Norway, I wouldn't be surprised if it is due to a
difference between //Bokmål and Nynorsk.

tl;dr version fix the street tagging and it will work .

Simon

Am 23.08.2020 um 21:41 schrieb Maarten Deen:
> Node 3117603944 was established in 2014 with tags
> addr:city Sørkjosen
> addr:housenumber 45
> addr:postcode 9152
> addr:street Ringvegen
>
> Yet, when I query nominatim for Ringvegen 45 Sørkjosen I get no results.
>
> What is going wrong here? Sørkjosen itself is found [2] so the problem
> does not seem to lie in the special character (I wouldn't have thought
> so). Also found is the street which is named Ringveien [3] in OSM. No
> idea why the street is called different than the address node, but
> does Nominatim not index address nodes?
>
> The reason why I was looking for this node is because it has a Tesla
> supercharger [4] on address 45 Ringvegen 9152 Sørkjosen.
>
> [1] https://www.openstreetmap.org/node/3117603944
> [2] https://nominatim.openstreetmap.org/ui/search.html?q=S%C3%B8rkjosen
> [3]
> https://nominatim.openstreetmap.org/ui/search.html?q=S%C3%B8rkjosen+ringveien
> [4]
> https://www.tesla.com/nl_NL/findus/location/supercharger/sorkjosensupercharger
>
> Regards,
> Maarten
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk


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

Re: [OSM-talk] New API suggestion: Allowing contributors to easily track their OSM-objects over time

[Simon Poole]

As, independent of any other concerns, a matter of good form, I would
want to point out that there is no such thing as ownership of
OSM-objects, and discussing a concept of "their OSM-objects" is starting
the discussion on the wrong foot.

Am 22.08.2020 um 11:08 schrieb pangoSE:
> Hi
>
> I would like to track all objects that I ever created or edited.
> I suggest we implement a system to make this easy.
>
> I suggest we create a new system that is updated every time a
> changeset is uploaded. The new system tracks userids and osmids and
> date of last change/edit.
>
> When I create or edit an object an entry is made in this system (if a
> way is converted to relation the relation id is added and so forth).
> If another user converts my way to a relation the system edits the
> userobjects table of both users. This works around the problem of
> missing permanent ids. If a node, way or relation is deleted by anyone
> the row in my userobjects is deleted)
>
> The system can then be queried lke this:
>
> IMPLEMENTATION SUGGESTION:
>
> GET Openstreetmap.org/api/userobjects/pangoSE
> Outputs objects for user pangoSE with the oldest first (outputs 10
> entries, &offset can be used to get more, &size can be used to output
> up to 300 entries, &modified_date=desc by default)
>
> The osmids of the objects can then be used to query the suggested
> verification endpoint to easily find old userobjects that are stale
> and need reverification. The user can be used to generate maps and gpx
> exports of all osmids needing verification for the user to use during
> a mapping quest.
>
> This data is privacy sensitive so the endpoint should require
> permissions from the user to make it easy to write a script or service
> that uses the data on behalf of the user.
>
> WDYT?
>
> Cheers
> pangoSE
> -- 
> Skickat från min Android-enhet med k9.
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk


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

Re: [OSM-talk] Use of OSM data without attribution

[Simon Poole]

To add to what Andy has already said, complaints about people using
private paths etc are relatively common, not a large number in absolute
terms, but there tend to be a couple each month which either land with
the DWG, or LWG, or naturally with the local community (I've handled a
couple of them with a different hat on locally, but they are rare).

AllTrails is just one of a handful of sources for such issues. I suspect
that it is simply that such ways that are not part of the public road
network tend to be less stable and sometimes not as well surveyed that
makes this more likely to happen. On top of that right of way and access
legislation tends to differ widely among countries, and what is
completely OK in one may find you at the wrong end of a shotgun in
another and that AllTrails et al are not very good in reflecting that.
Example:  highway=track in the UK, which should probably default to
access=private, but here and say in DE, in general would always have
public access except if signposted differently or gated.

Simon

Am 22.08.2020 um 00:33 schrieb Martijn van Exel:
> Curious anecdote: some AllTrails user apparently looked up a phone
> number for OSM US and called up Maggie. Turns out the complaint was
> about a trail that I originally mapped *blush*. In my defense, that
> was 9 years ago, I haven't been to that part of town much since I
> moved, and nobody else updated the trail, which has since disappeared.
>
> Here is the changeset in case you're interested:
> https://www.openstreetmap.org/changeset/89419938
>
> Martijn
>
> On 8/19/2020 3:44 PM, Clifford Snow wrote:
>> Hey Mike,
>> They definitely mention OSM, even call us a partner [1] but like you
>> found their basemap is definitely OSM. Instead of suggesting their
>> users edit OSM, they instead instruct them to email
>> d...@openstreetmap.org <mailto:d...@openstreetmap.org>,
>>
>> All Trails is located in SF but I couldn't find any listing of a
>> leadership team.
>>
>> Do you want to ask on Slack? Someone there might have a connection.
>>
>>
>> [1]
>> https://support.alltrails.com/hc/en-us/articles/360018930672-How-do-I-update-or-change-information-about-a-trail-
>>
>> On Wed, Aug 19, 2020 at 1:03 PM Mike Thompson > <mailto:miketh...@gmail.com>> wrote:
>>
>>     Has anyone tried contacting the AllTrails[0] people about their
>>     use of OSM without attribution?  I am not talking about the "OSM
>>     Map Layer" that they offer, but rather the default "AllTrails Map
>>     Layer."  At the very least it appears that the trails on that
>>     layer come from OSM.  I know that because I have entered some
>>     rather obscure informal trails in OSMe, and they show up in
>>     AllTrails just as I entered them in OSM.
>>     Mike
>>
>>     [0] https://www.alltrails.com/ (in the search box enter the name
>>     of a trail, park, or city to see their map.)
>>     ___
>>     talk mailing list
>>     talk@openstreetmap.org <mailto:talk@openstreetmap.org>
>>     https://lists.openstreetmap.org/listinfo/talk
>>
>>
>>
>> -- 
>> @osm_washington
>> www.snowandsnow.us <https://www.snowandsnow.us>
>> OpenStreetMap: Maps with a human touch
>>
>> ___
>> talk mailing list
>> talk@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk



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

Re: [OSM-talk] Roadmap for deprecation of name tags in OSM

[Simon Poole]

The "names" in wikidata are mostly the names of WP pages for the object
in question and have little to do with actually existing names (as per
the OSM definition) of places.

It would be a massive drop in quality if we would do the proposed switch.

Simon

Am 09.08.2020 um 10:25 schrieb pangoSE:
> I suggest we create a roadmap for deprecating of storing and updating
> names in OSM for objects with a Wikidata tag.
>
> The rationale is explained here:
> https://josm.openstreetmap.de/ticket/19655
>
> This of course affects the whole project and data consumers as well.
> Every OSM user will have to become a Wikidata user as well to edit the
> names or add name references (through the editors)
>
> Substantial changes will have to be made:
> * nominatim will need to support fetching names from wikidata somehow.
> It could probably be done on the fly.
> * openstreetmap.org will need to fetch from wikidata when displaying
> any object.
> * rendering the standard map will have to support fetching from wikidata.
> * all editors would have to fetch and enable editing of Wikidata objects.
> * maybe it no longer makes sense to have 2 separate logins? We should
> unify the logging in as much as possible. Ideas are welcome on how to
> do that. Perhaps retire signing up as OSM user on osm.org and ask
> users to create a Wikimedia account instead and log in with that?
>
> I personally don't see any problems connecting Wikimedia and OSM
> closer than the islands they are today.
>
> As mentioned in the ticket above data consumers like Mapbox already
> prefer Wikidata names. I'm guessing thats because they are simply
> better quality, better modeled, better referenced and better protected
> against vandalism.
>
> WDYT?
>
> Cheers
> pangoSE
> Ps I choose this list because this not only relates to tagging, but to
> the wider ecosystem.
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk


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

Re: [OSM-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2

[Simon Poole]

Am 04.08.2020 um 17:05 schrieb Alexandre Oliveira:
>> At this time nobody is proposing anything more than giving P2 a bit more 
>> life for a small sum of money
> And as myself and others have brought up, it's not a good idea to
> spend money to port P2 from a dead technology to another dead
> technology, if people still use it it's much more beneficial in the
> long term to port it to modern web technologies than have to spend a
> few thousand bucks every once in a while to port a software that's
> pretty important for OSM (even though its usage has decreased over the
> years the changeset amount is still high) to another dead technology.
The problem with that is that it implies 2 to 3 more zeros (at least)
before the decimal point in the costs, and -then- the question really
arises why we are doing that. Literally nobody including Richard has
proposed to spend more money down the road, and given that he tends to
be relatively down to earth I assume he is not expecting eternal support.
>
> As someone (I can't recall who it was) said, "$2500 is not much", then
> if the OSMF wants to spend it on useless efforts (i.e. porting P2 from
> Flash to Air) then why not give it to me then, if the OSMF wants to
> spend this money? :P Jokes aside, if the OSMF really wants to spend
> this money I'd suggest it to be spent somewhere else if the board is
> so keen on setting up life support and going through the stress that
> it is to maintain dead libraries.

The reason is that the users want to continue to use P2 for now (see
discussion in the forum for example). To put this in to perspective we
are talking about a one time spend of about 1 € per head, somewhat less
than what iD costs per year (every year), and at least an order of
magnitude less than the same for JOSM etc.

Simon 




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

Re: [OSM-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2

[Simon Poole]

Could we move all the programming language du jour fanboying, apps that
have nothing to do OSM and other unrelated to the topic discussions
somewhere else please?

And yes it underlines my point that regardless of how exotic the feature
is, you are always going to find somebody that finds it critical to
success (this one of the reasons why JOSM has three variants of
everything), but it isn't a good measure of what the OSMF should spend
its money on, weere applying an 80/20 rule is likely to be far more
appropriate.

At this time nobody is proposing anything more than giving P2 a bit more
life for a small sum of money, if Richard has a plan for longer term
maintenance and development then that should be considered when
proposed. Definitely nobody is going to embark on the multi-million
undertaking that writing and bringing to production a new editor is,
just on the base that it would be cool to write one in .

Simon

Am 04.08.2020 um 16:26 schrieb Matthew Woehlke:
> On 04/08/2020 08.10, Martin Koppenhoefer wrote:
>> On 4. Aug 2020, at 13:58, Matthew Woehlke wrote:
>>> but I would practically *kill* for JOSM to have FreeCAD's suite of
>>> sketch constraints ;-).
>>
>> you’re aware that there are sketch constraints for configurable
>> angles (90, 60, 45 etc) and projection snaps? Hit 2 times „a“ (angle
>> display becomes green)
> Yes. They're better than nothing, but nowhere near what I'm talking
> about. As an example, consider the attached simple FreeCAD sketch
> which is roughly representative of some buildings I've mapped
> recently. The dome in front is centered (segments on either side
> constrained to be equal). The "wings" in back are symmetrical.
>
> It's *possible* to do this sort of thing in JOSM with a lot of care
> and by building part of the geometry, then constructing a bunch of
> "scratch" geometry in order to construct a symmetry line, then doing a
> copy, paste in place, mirror, reverse, stitch the parts together...
> but God help you if you make a mistake and have to start over.
>
> In FreeCAD, you just slap on some equality constraints, angle
> constraints, parallel constraints, etc. and then you can *move* any of
> the nodes and everything else will update to preserve the applied
> constraints. (The one things it's missing that would be helpful is a
> *colinear* constraint; you have to simulate that with parallel and
> coincident constraints using "construction" lines; those are the blue
> ones. A colinear constraint could eliminate the need for those
> construction lines.) This is the major difference, though. In JOSM,
> constraints only apply when you initially draw something, so if you
> get it wrong, you have to start over. In FreeCAD, they're a dynamic
> system; if you get it wrong, just nudge it and the whole thing updates
> *while preserving your constraints*.
>
> Oh, and *arcs*. The ability to define a segment that should be a
> perfect arc, and optionally make it tangent or perpendicular to its
> neighbors, would be a major boon. Again, I can fake it with a bunch of
> scratch construction, but if it's wrong, I have to start over and hope
> my next guess is better. In FreeCAD, just drag the end points until it
> looks right.
>
> Then there are distance constraints, which would be incredibly useful
> if you're mapping something with known dimensions.
>
> Seriously, give FreeCAD a spin. It's pretty awesome for this sort of
> relatively simple 2D stuff. Also look at some of the buildings I've
> done recently; the symmetrical ones don't just *look* symmetrical,
> they *are* symmetrical (within the limits of JOSM's abilities). I've
> also done a lot of stuff like roads that are perfectly centered in
> between parking spaces, groups of aligned buildings that are
> *actually* aligned, and whatnot. It's do-able, but it would be *s*
> much easier with FreeCAD-style constraints.
>
> Obviously, this would all almost surely be a temporary mode (maybe it
> persists as long as JOSM is open, but isn't uploaded), but since you
> usually draw once, that would be fine. (Bonus points if JOSM could
> automatically recreate constraints for ways that don't have any. It
> shouldn't be hard to guess equality, perpendicular and colinear
> constraints, at least.)
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk


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

Re: [OSM-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2

[Simon Poole]

Am 02.08.2020 um 11:31 schrieb mmd:
> ...
> In a more mid-term, I really like to see a move away from such
> proprietary platforms to an editor that runs in a browser
> out-of-the-box. 

...

Don't we already have that?




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

Re: [OSM-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2

[Simon Poole]

Am 02.08.2020 um 01:03 schrieb Skyler Hawthorne:
> ...
>
> Sorry if this sounds harsh, but I think using any funds at all to
> continue support for a tool that 1% of editors use would be wasteful.
> Flash is, for all intents and purposes, a dead technology. This money
> is better spent on other uses.
> ...

Extending this a bit further, you could just as well say, given that all
current and actively maintained general purpose editors require 1-2
FTEs, the OSMF should simply block all non-iD editors and tell the
developers to either work on iD or go home.

In reality things are not quite that simple,  it starts with measuring
how much use an app actually gets.

While iD outstrips JOSM substantially wrt users (JOSM has less than 10%
market share), a majority of the iD users have a very small number of
edits and are non recurring contributors. This reflects itself in the
edit counts too where the ratio is ~2/3 JOSM and 1/3 id. Naturally JOSM
-currently- tends to get used for larger edits which is likely a major
factor. Given that P2 users are mostly long time OSM contributors that
edit regularly, a similar pattern can be seen, and I think that a one
time update at the proposed cost can easily be justified.

Now medium term, that is 1-2 years, this is likely going to change
substantially. iD is branching out in to more and more niches, reducing
the breathing space for anything else massively and other editor use has
effectively been stagnating for a long time. While people will
automatically try to start listing special use cases that can "only" be
done with editor XX, the problem is that these are special cases and
unlikely to be worth spending a couple of $100k on per year (virtually
or real) for the small number of users that will remain as iD gains more
and more features.

Simon




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

Re: [OSM-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2

[Simon Poole]

That was a good decade ago, nothing that would factor in to a decision
now (because Linux could not be a target platform to start with). 

Am 01.08.2020 um 10:16 schrieb Sören Reinecke via talk:
> So far as I understood Adobe dropped Linux support for its AIR
> plattform. If that is right, then I am in doubt that supporting the
> development of Potlatch 2 is not that in a sustainable manner.
>
> Cheers
>
> Sören Reinecke
>
>
>  Original Message 
> Subject: [OSM-talk] Funding of three infrastructure projects :
> Nominatim, osm2pgsql, Potlatch 2
> From: Guillaume Rischard
> To: OSMF Talk
> CC: OpenStreetMap talk mailing list
>
>
>   Hi all,
>
> The OSMF Board wants to facilitate and support improving
> infrastructure. During the Microgrants process, there were
> proposals that didn’t make it, but would together be a good pilot
> for a “OSM infrastructure” process, to learn how supporting osm
> infrastructure projects works well.
>
> The OSMF Board wants to fund a limited number of projects proposed
> by trusted long-term volunteers whose work we know and enjoy. We
> have selected the osm2pgsql and Potlatch microgrant proposals, and
> have a new proposal from Nominatim.
>
> In the long term, we want to re-activate the Engineering Working
> Group (EWG) by making it a place for decision making, project
> guidance and budget management for such projects.
>
> The Board would like your feedback on these three specific
> infrastructure projects:
>
>
> Nominatim
>
> Nominatim is the geocoding software that powers openstreetmap.org
> and many other apps and websites. Sarah wants to work on:
> 
>
>  *
>
> finishing the localization efforts (improve address
> computation for different countries, localized address output)
>
>  *
>
> making the software more user-friendly (reduce the number of
> programming languages by at least two, move side-projects into
> separate repos, reorganise the code so that Nominatim can
> become an Ubuntu package, docs, docs, docs)
>
> The full proposal is at
> https://wiki.osmfoundation.org/wiki/Nominatim_project_2020-07
>
>
> Potlatch 2
>
> Potlatch 2 used to be the default editor before iD took the relay.
> While usage is declining, it’s still used by 2500 (1.4%) users who
> did 10 million (1.2%) changes in 2020.
> 
>
> Potlatch is built in Flash, which browsers will retire by the end
> of the year. Richard wants to adapt Potlatch 2 to the AIR platform
> so users who still rely on it can continue to use it.
>
> The full proposal is at
> 
> https://wiki.openstreetmap.org/wiki/Microgrants/Microgrants_2020/Proposal/Potlatch_2_for_desktop
>
>
>
> osm2pgsql
>
> osm2pgsql loads OpenStreetMap data into databases suitable for
> applications like rendering into maps, geocoding with Nominatim,
> or general analysis. It is used on openstreetmap.org and in many
> other places. 
>
> While there has been constant paid and volunteer work on
> osm2pgsql, large scale architecture changes to pay off historical
> technical debt are needed to tackle long term challenges, and make
> future changes easier.
>
> Jochen wants to work on:
>
>  *
>
> Hosting documentation on osm2pgsql.org 
>
>  *
>
> Rethinking the output of the program to make it more concise
> and useful
>
>  *
>
> Tackling the refactoring and cleanup of the “middle” code.
>
>  *
>
> Ongoing maintenance as needed
>
>  *
>
> Other work from the road map as time permits
>
> The original budget and scope were limited by the microgrant
> framework. The current project goes beyond that, and addresses
> open issues and potential improvements further and better.
>
> The proposal is at
> https://wiki.osmfoundation.org/wiki/Osm2pgsql_project_2020-07
>
>
>
>
> Thank you and happy mapping
>
> Guillaume, for the OSMF board
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk


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

Re: [OSM-talk] Facebook acquires crowdsourced mapping company Mapillary

[Simon Poole]

Am 19.06.2020 um 13:47 schrieb Nick Whitelegg:
>
> (Disclaimer: I am the developer of said project)

One of the key functionalities required for such a project to be useable
in countries with developed privacy regulation is the ability to
automatically pixelate relevant parts of the images with a high degree
of reliability. It took Mapillary literally years to get that nailed
down and bring it to the level of functionality it is at now.


Which is one of the reasons why, way back when Mapillary started, I was
sceptical about the sustainability because the part of the product the
detection is required don't have a real associated revenue stream
(except if you a google, or ... and can use it in one way or the other
to sell ads).


In any case doing that from scratch would be a real pain. I believe the
OSC stack is now actually all OSS which would be a far better starting
point -if- sustainable funding could be built around the whole thing.


Simon


PS: naturally the whole reason for OSC was a business dispute that is
now moot because Mapillary is opening up its images for commercial use too.


>
> Those of you looking for 100% FOSS software and who are focused on 360
> degree photography of off-road routes (walking trails and so on) might
> want to consider OpenTrailView (https://opentrailview.org). Do bear in
> mind that it is in the early stages of development, so don't expect
> Mapillary-style UX just yet, and there is only a small amount of
> imagery (largely southern England at the moment plus a few around
> Heidelberg for probably obvious reasons) but it is in active
> development and I do have a possible collaboration with another
> project (more on that later).
>
> OpenTrailVIew also uses underlying OpenStreetMap data to auto-connect
> panoramas, using GeoJSON Path Finder
> (github.com/perliedman/geojson-path-finder), though, due to server
> capacity constraints, this only works at present in Europe and Turkey
> (though requests for other countries welcome, though note that if they
> are for large and/or highly-populated countries countries such as the
> USA, China or Brazil I would have to restrict it to a region).
>
> You can login using your OSM account.
>
> Nick
> 
> *From:* Florian Lohoff 
> *Sent:* 19 June 2020 07:58
> *To:* Niels Elgaard Larsen 
> *Cc:* talk@openstreetmap.org 
> *Subject:* Re: [OSM-talk] Facebook acquires crowdsourced mapping
> company Mapillary
>  
> On Fri, Jun 19, 2020 at 01:21:59AM +0200, Niels Elgaard Larsen wrote:
> > Paul Johnson:
> > > Great.  How's this affect those of us who trust Facebook about as
> far as we can throw it?
> >
> >
> > Use openstreetcam
>
> Openstreetcam is pretty much "disfunct" from my perspective. There are
> tons of bugs people opened because of their tracks not beeing
> processing. Same for me. Twitter feed dead for a year. It looks pretty
> much abandoned since end of 2019 - Since early June serious problems
> processing tracks and uploads.
>
> And for the me focus on Car driveable streets makes it useless.
>
> Flo
> -- 
> Florian Lohoff f...@zz.de
>     UTF-8 Test: The 🐈 ran after a 🐁, but the 🐁 ran away
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk


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

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

[Simon Poole]

I've advocated for this in the past,  but getting this right from a
business logic pov is fairly tricky and is yet another thing that an
editor needs to keep track of when creating and modify geometries, and
changing tags. From the top my head at least: new object creation,
dragging nodes and ways, merging and splitting ways, adding and removing
relation members, copy, cut and paste, all tag changes. While each of
these might be minor things, all together they have a clear performance
and complexity impact and require UI additions to handle. This is
assuming that such a bounding box limit would not be enforced by the
API, if enforced you actively have to not allow the user to make the
change which is even more painful.

If the limit is enforced there are all kinds of vandalism/DoS scenarios
that would probably require lifting the restriction for admins/mods.  

And all this because of a API defect (because there is just one bounding
box per changeset instead of a list)?

Simon

Am 12.06.2020 um 13:00 schrieb Frederik Ramm:
> Hi,
>
> 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.
> Something like "you have unsaved edits more than 500km away from where
> you are editing at the moment, please upload those before you continue"
> or so.
>
> World-spanning changesets are a constant source of irritation, and very
> rarely intentional.
>
> Bye
> Frederik
>



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

Re: [OSM-talk] Toward resolution of controversies related to iD

[Simon Poole]

Am 09.06.2020 um 18:04 schrieb nd...@redhazel.co.uk:
> 
> Who owns the iD project now? What's happened after "nearly all of the
> original authors left Mapbox", has the project ownership been
> transferred from Mapbox to OSMF, or perhaps to current maintainers?
> Does Mapbox still retain the ownership rights to the project (even if
> they don't currently care about them)?
I don't think that is a particularly relevant question, but at least the
non-forked code base currently is at https://github.com/openstreetmap/iD
>
> The code license is very permissive so there is always an option of
> starting a new project based on it (forking). But the license and
> ownership of the project are not the same thing.

iD doesn't require any rights assignment to have contributions accepted,
so again I'm not sure that that is a meaningful question. The IP rights
in the code are owned by individuals contributing, and given that the
major part of the code was work for hire*, by the companies employing
them. But this would only be relevant in the case of re-licensing in any
form.

>
>> Many would have argued that the OSMF should have received the half a
>> million dollars  and contracted the work out, maybe to Mapbox, but in
>> any case just because what actually happened was slightly different,
>> doesn't mean that the OSMF and the OSM community gave whoever happens to
>> be working on iD the licence to control the projects destiny forever.
>
> Not saying that this shouldn't be the case, but clearly it wasn't, at
> least initially. And if it isn't ours we can't simply take it, even if
> we really, really want it.

As Frederik pointed out, without the OSMF agreeing to distribute the
code and host it on openstreetmap.org the project would have been a
non-starter. Your whole concept that this is something that developed
independently and now there is now a grab by the OSMF to control it  is
completely at odds with reality, most of the issues are actually due to
the OSMF -not- exercising its power in the past which is what this
initiative is trying to address.

>
> From my point of view - I am happy with the current project
> governance. It works well for iD, it works well for the OSM community.
> Controversies are all around minor issues and contributions -
> basically saying that the maintainers are doing their job.
>
Many people will disagree with that.

Simon

* "naturally", well it is one of the issues, the OSMF doesn't have any
direct knowledge of the terms of employment of the relevant individuals,
so this is a bit of speculation.

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



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

Re: [OSM-talk] Toward resolution of controversies related to iD

[Simon Poole]

Am 09.06.2020 um 14:18 schrieb Mikel Maron:
> ---
>
> As it should be.

Mapbox developers decide on (not just  have input on) budgets, product
specs etc etc etc etc etc etc for the company?




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

Re: [OSM-talk] Toward resolution of controversies related to iD

[Simon Poole]

Frederik has already corrected most of your misconceptions, so just some
additional comments;

Am 09.06.2020 um 12:32 schrieb nd...@redhazel.co.uk:
>
> - Taking control from the original authors would slow down, if not
> stall, the development of iD.
>
Nearly all of the original authors left Mapbox a long time ago, nobody
working on it today is an "original author". The grant that Mapbox
received at the time was clearly instrumental in allowing them to start
growing the company to its current size, so while we are obviously
thankful for the support that Mapbox has provided over the years, it was
clearly a win-win situation.

Many would have argued that the OSMF should have received the half a
million dollars  and contracted the work out, maybe to Mapbox, but in
any case just because what actually happened was slightly different,
doesn't mean that the OSMF and the OSM community gave whoever happens to
be working on iD the licence to control the projects destiny forever.

Simon




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

Re: [OSM-talk] Search results quality (and some testing on Elasticsearch)

[Simon Poole]

Hi Jose

Maybe you should have a look at  https://github.com/komoot/photon which
is the go to ES based solution for OSM data (I'm not quite sure how you
missed it with the large amount of research you did, but anyway).

The other bit to understand is that the design goals of Nominatim, at
least historically, were not "return a result at all cost" but, "return
a result if the object is tagged correctly", which goes hand in hand
with the target audience and goals of the openstreetmap.org. In any case
the main reason we're not running photon on openstreetmap.org are mainly
operational, not technical (aka somebody needs to volunteer to a)
integrate it in to the web site, b) integrate it in to our chef
deployment, c) provide operational support).

Simon

Am 29.05.2020 um 04:19 schrieb José Juan Montes:
>
> Hi all,
>
> This is my first message to the list so I take the opportunity to say
> hello to all and thanks to the community for the awesome
> software, data, and organisation.
>
> Now to the point. At the ES comunity, we've been discussing how
> difficult is to obtain useful results from OSM. Too many times results
> are odd or surprising: ordering puts better results down, sometimes it
> misses obvious matches entirely... Specifically, we are referring
> about the search engine of OSM front page, and other Nominatim
> bsaed services. 
>
> After some anaysis, issues seem related to:
>
> - stop words usage (prepositions, articles...)
> - result scoring and ordering (a perfect match placed below far and
> unrelated results)
> - word matching when there are tildes or non-unicode chars
> - synonyms / ignoring for some categories and common nouns (street /
> road...)
> - lack of autocompletion (helps users finding a result when they don't
> quite know the exact term)
> - lack of cross-langugae search (eg. in regions with several official
> languages, people mixes street names and road types between languages)
> - support for typo errors
>
> Part of the problem is that every language requires particular
> considerations, which impacts most of the points above. So in my view,
> a suitable solution would need to have good i18n support bottom up.
>
> We think that other communities (language-wise) may be hitting the
> same issues according to Github issues. I list some references at the
> bottom, but they don't seem to get much attention.
>
> Ultimately, the technology stack Nominatim is built upon is not state
> of the art. I have done a quick test with Elasticsearch and a simple
> default installation with naive data loading already produces decent
> results. I later found that alternative search engines exist, for
> example "Pelias", which are implemented on top of newer technologies,
> and their demo seems to work fine... 
>
> Has any alternative to the current geocoder been tested? What would it
> take for this to be improved? If alternatives exist, can the search
> engine at the front page be changed? or provide options so users can
> choose their preferred search engine? maybe even from specialized
> local/themed search providers? Perhaps something like that would pave
> the way for alternative search software and services, and foster
> innovation. 
>
> Cheers!
>
> Refs:
>
> - https://github.com/osm-search/Nominatim/issues/1811
> - https://github.com/osm-search/Nominatim/issues/333
> - https://github.com/osm-search/Nominatim/issues/1208
> - https://wiki.openstreetmap.org/wiki/Search_engines
> - source code of my
> tests: https://github.com/jjmontesl/cubetl/tree/master/examples/osm
>
>
> Jose Juan Montes
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk


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

Re: [OSM-talk] talk Digest, Vol 189, Issue 24

[Simon Poole]

Hi Allan

The question is which WG would that be? Sad to say but I don't believe
there is any group that has a more holistic view of the software side of
things and is actually willing to go through the gyrations of producing
a budget and then spending the money (just see the osmosis near
debacle), maybe way back it was the EWG, but that was more than a decade
ago.

Back to the specifics: the askbot fork of QSQA, the software running on
the help site, is not hyperactive but not totally dead either and I
should note that the software stack it uses isn't particularly exotic
either. There is no reason to believe that we couldn't migrate to that
and get some support from the developer (for money obviously). It would
make a lot more sense than any other alternative outside of shutting the
whole thing down (which would be the OSM way).

Simon

Am 20.05.2020 um 23:17 schrieb Allan Mustard:
>
> Simon, et al, if money is required from the OSMF, could not one of the
> working groups submit a funding request for migration to a new
> platform like StackExchange?  Microgrant is probably not appropriate
> for something like this.  Just my two cents' worth.
>
> apm
>
> On 5/20/2020 4:42 PM, talk-requ...@openstreetmap.org wrote:
>> Send talk mailing list submissions to
>>  talk@openstreetmap.org
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>>  https://lists.openstreetmap.org/listinfo/talk
>> or, via email, send a message with subject or body 'help' to
>>  talk-requ...@openstreetmap.org
>>
>> You can reach the person managing the list at
>>  talk-ow...@openstreetmap.org
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of talk digest..."
>>
>>
>> Today's Topics:
>>
>>1. Re: our Q&A site help.openstreetmap.org is dying
>>   (Mateusz Konieczny)
>>2. Re: our Q&A site help.openstreetmap.org is dying (Tom Hughes)
>>3. Re: our Q&A site help.openstreetmap.org is dying (Lester Caine)
>>4. Re: our Q&A site help.openstreetmap.org is dying (Simon Poole)
>>5. Re: our Q&A site help.openstreetmap.org is dying (Tobias Wrede)
>>6. Re: our Q&A site help.openstreetmap.org is dying (Frederik Ramm)
>>7. Re: our Q&A site help.openstreetmap.org is dying (Tobias Wrede)
>>8. Re: our Q&A site help.openstreetmap.org is dying (James)
>>
>>
>> --
>>
>> Message: 1
>> Date: Wed, 20 May 2020 15:48:27 +0200 (CEST)
>> From: Mateusz Konieczny 
>> To: Tobias Wrede 
>> Cc: Talk 
>> Subject: Re: [OSM-talk] our Q&A site help.openstreetmap.org is dying
>> Message-ID: 
>> Content-Type: text/plain; charset="utf-8"
>>
>>
>>
>>
>> May 20, 2020, 09:28 by l...@tobias-wrede.de:
>>
>>> Can we involve any of the OSM organizations to find, maybe pay, someone? 
>>>
>> The question is about the plan. Life support for this specific platform?
>>
>> It sounds like an endless pit that can consume plenty of resources,
>> but maybe I am too pessimistic.
>>
>> Migrate to Stack Exchange? Even assuming that this company will agree
>> it has plenty of potential issues.
>>
>> Wait for someone to volunteer and fix? It would be nice, but not sure what
>> are chances of that.
>> -- next part --
>> An HTML attachment was scrubbed...
>> URL: 
>> <http://lists.openstreetmap.org/pipermail/talk/attachments/20200520/1710766f/attachment-0001.htm>
>>
>> --
>>
>> Message: 2
>> Date: Wed, 20 May 2020 15:12:58 +0100
>> From: Tom Hughes 
>> To: Mateusz Konieczny , Tobias Wrede
>>  
>> Cc: Talk 
>> Subject: Re: [OSM-talk] our Q&A site help.openstreetmap.org is dying
>> Message-ID: <15f2bcdf-981f-19e7-224f-8b92f6574...@compton.nu>
>> Content-Type: text/plain; charset=utf-8; format=flowed
>>
>> On 20/05/2020 14:48, Mateusz Konieczny via talk wrote:
>>
>>
>>> Migrate to Stack Exchange? Even assuming that this company will agree
>>> it has plenty of potential issues.
>> They have a public process for proposing new sites:
>>
>>https://area51.stackexchange.com/faq
>>
>> So long as enough people are interested it shouldn't be an issue. I've
>> been through the process with another site.
>>
>> Tom
>>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk


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

Re: [OSM-talk] our Q&A site help.openstreetmap.org is dying

[Simon Poole]

Am 20.05.2020 um 15:45 schrieb Mateusz Konieczny via talk:
> Well, if nobody will volunteer to fix it then we will need to select
> between
> stack exchange migration and simply killing the QA site.

We could simply pay for the migration (and if necessary for some support
going forward), the thing is that we would rather sprinkle fairy dust
around (see below).

>
> And from going through microgrants proposals nobody is willing to
> work on this even with a subsidy.

It is clearly outside of the scope of the micro grants, well at least it
was, it is unclear if the whole concept has morphed away from what was
originally presented (aka to contain stuff  that should be in the
regular budgets of the OSMF and LCs).

Simon




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

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

[Simon Poole]

Am 13.05.2020 um 13:46 schrieb Mateusz Konieczny via talk:
...
> And, no, a typical user will not click on a hidden button or check
> deeply in settings.
>
...

Nobody ever even remotely indicated that attribution via a "hidden
button" or deep in any settings was sufficient, in fact the draft
guideline contained the opposite. Now I do realize the value of
exaggeration as a rhetoric device, but, as obvious from this thread, it
does confuse people as to what the actual facts are.

Simon




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

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

[Simon Poole]

Am 12.05.2020 um 23:03 schrieb Mateusz Konieczny via talk:
>
>
>
> May 12, 2020, 05:48 by rockyt...@gmail.com:
>
>
> As Joseph said:
>
> The attribution goes on the map.
> This is not a difficult requirement to meet.
>
>
> 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.
>
>
> Is there anywhere I can share my two cents about the guidelines?
>
> I commented on
> https://wiki.openstreetmap.org/wiki/Talk:Draft_Attribution_Guideline
> but I am unsure is it a good place because I got no reply.

Expecting a reply is unreasonable, taking the comments in to account not
(which we did).

>
> One may also join online meeting of a Legal Working Group
> and talk there.
>
> https://wiki.osmfoundation.org/wiki/Licensing_Working_Group
> "The group now meets every 2nd Thursday of the month, at 20:00 UTC, on
> Mumble <https://wiki.openstreetmap.org/wiki/Mumble>, unless rescheduled."
>
As you know the LWG has handed the subject back to the board months ago,
not to mention that we provided ample time and venues to provide input
on the matter and that is long closed. Just because somebody wasn't
paying attention doesn't mean that you restart a process when they turn
up and feel they have a right to their opinion being heard*.

Simon

* that was one of the main reasons the OSM licence change was such a
traumatic experience.



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


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

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

[Simon Poole]

Am 2. Mai 2020 15:44:33 MESZ schrieb Christoph Hormann :
>
>> The only time in the past this 
>was done was with the change to the ODbL in 2012 IIRC.

That is not correct, the licence change process has never been invoked.


-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit Kaiten Mail gesendet.

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

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

[Simon Poole]

Am 27.04.2020 um 19:49 schrieb Alexandre Oliveira:
> Hello!
>
> I'll try to be brief and explain the main problems that exist with
> OSM's way of handling lack of (proper) attribution.
>
There was just a (nearly 100 messages) long thread on the subject here 
not to mention a longish consultation last year, with multiple in person
sessions, which covered all the issues you touch on.

Simon 




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

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

[Simon Poole]

Am 17.04.2020 um 13:20 schrieb Christoph Hormann:
> ...
> Independent of what the OSMF suggests in the future - i would probably 
> continue attributing "OpenStreetMap contributors" where feasible to 
> clarify that i am crediting the contributors and not the OSMF.

With the exception of imported datasources that are not re-licensable,
you do realise though that the actual licensor of the data -is- the
OSMF? And that attributing "OpenstreetMap contributors" is at best a
sentimental relict (nothing against being sentimental, but that isn't
your argument) and is, if anything, more confusing and misleading than
simply asking for an attribution string that credits the project?

Simon




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

Re: [OSM-talk] Replication errors

[Simon Poole]

Sarah has already given the answer, but a small remark anyway: I would
suggest following the operations twitter account
https://twitter.com/OSM_Tech as that is the place you are most likely to
see short term notices about these kind of things.

Simon

Am 16.04.2020 um 08:10 schrieb Andrzej Kępys:
> Hi All!
>
> Since few days I have a replication errors using osmosis... Any ideas
> how to fix it? Is there anythink I can do or it's sth about a data?
>
> ---START
> Thu Apr 16 08:05:01 CEST 2020
> No current.osc file found, downloading new one...
> Apr 16, 2020 8:05:02 AM org.openstreetmap.osmosis.core.Osmosis run
> INFO: Osmosis Version 0.46
> Apr 16, 2020 8:05:02 AM org.openstreetmap.osmosis.core.Osmosis run
> INFO: Preparing pipeline.
> Apr 16, 2020 8:05:02 AM org.openstreetmap.osmosis.core.Osmosis run
> INFO: Launching pipeline execution.
> Apr 16, 2020 8:05:02 AM org.openstreetmap.osmosis.core.Osmosis run
> INFO: Pipeline executing, waiting for completion.
> Apr 16, 2020 8:05:03 AM
> org.openstreetmap.osmosis.core.pipeline.common.ActiveTaskManager
> waitForCompletion
> SEVERE: Thread for task 1-read-replication-interval failed
> org.openstreetmap.osmosis.core.OsmosisRuntimeException: Unable to
> parse xml file /tmp/change8964114732320454958.tmp.  publicId=(null),
> systemId=(null), lineNumber=1775, columnNumber=22.
> at
> org.openstreetmap.osmosis.xml.v0_6.XmlChangeReader.run(XmlChangeReader.java:100)
> at
> org.openstreetmap.osmosis.replication.v0_6.ReplicationDownloader.processChangeset(ReplicationDownloader.java:107)
> at
> org.openstreetmap.osmosis.replication.v0_6.BaseReplicationDownloader.processReplicationFile(BaseReplicationDownloader.java:133)
> at
> org.openstreetmap.osmosis.replication.v0_6.BaseReplicationDownloader.download(BaseReplicationDownloader.java:235)
> at
> org.openstreetmap.osmosis.replication.v0_6.BaseReplicationDownloader.runImpl(BaseReplicationDownloader.java:271)
> at
> org.openstreetmap.osmosis.replication.v0_6.BaseReplicationDownloader.run(BaseReplicationDownloader.java:350)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: org.xml.sax.SAXParseException; lineNumber: 1775;
> columnNumber: 22; Invalid byte 2 of 4-byte UTF-8 sequence.
> at
> org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown
> Source)
> at org.apache.xerces.util.ErrorHandlerWrapper.fatalError(Unknown
> Source)
> at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown
> Source)
> at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown
> Source)
> at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
> Source)
> at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown
> Source)
> at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
> at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
> at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
> at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
> at
> org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
> at org.apache.xerces.jaxp.SAXParserImpl.parse(Unknown Source)
> at javax.xml.parsers.SAXParser.parse(SAXParser.java:195)
> at
> org.openstreetmap.osmosis.xml.v0_6.XmlChangeReader.run(XmlChangeReader.java:90)
> ... 6 more
> Caused by: org.apache.xerces.impl.io.MalformedByteSequenceException:
> Invalid byte 2 of 4-byte UTF-8 sequence.
> at org.apache.xerces.impl.io.UTF8Reader.invalidByte(Unknown Source)
> at org.apache.xerces.impl.io.UTF8Reader.read(Unknown Source)
> at org.apache.xerces.impl.XMLEntityScanner.load(Unknown Source)
> at org.apache.xerces.impl.XMLEntityScanner.scanLiteral(Unknown
> Source)
> at org.apache.xerces.impl.XMLScanner.scanAttributeValue(Unknown
> Source)
> at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanAttribute(Unknown
> Source)
> at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanStartElement(Unknown
> Source)
> ... 16 more
>
> Apr 16, 2020 8:05:03 AM org.openstreetmap.osmosis.core.Osmosis main
> SEVERE: Execution aborted.
> org.openstreetmap.osmosis.core.OsmosisRuntimeException: One or more
> tasks failed.
> at
> org.openstreetmap.osmosis.core.pipeline.common.Pipeline.waitForCompletion(Pipeline.java:146)
> at org.openstreetmap.osmosis.core.Osmosis.run(Osmosis.java:92)
> at org.openstreetmap.osmosis.core.Osmosis.main(Osmosis.java:37)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMetho

Re: [OSM-talk] healthsites.io breaks OSM data, do not use

[Simon Poole]

We currently are lacking a simple lightweight way of blocking write
access to the API, but it is being looked at.

This would normally be the ultima ratio as it essentially means all work
already done before an upload is lost, but in the case of a 1 change per
changeset app as healthsite.io it could be justified.

Simon

Am 21.03.2020 um 17:44 schrieb Mikel Maron:
> Yikes. Good catch and agreed. 
>
> Can anyone track the extent of the damage, and prepare to restore the thrown 
> away tags, while keeping the good new data?
>
> * Mikel Maron * +14152835207 @mikel s:mikelmaron
>
>
>
>
>
>
> On Saturday, March 21, 2020, 12:42:01 PM EDT, Frederik Ramm 
>  wrote: 
>
>
>
>
>
> Hi,
>
> the "healthsites.io" web app allows you to contribute data to OSM,
> however if you modify existing OSM objects, it throws away all tags it
> does not know of. Until this bug is fixed, please refrain from using
> healthsites.io!
>
> You can track progress here
> https://github.com/healthsites/healthsites/issues/1357#issuecomment-602068556
>
> Bye
> Frederik
>



signature.asc
Description: OpenPGP digital signature
___
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

[Simon Poole]

Am 20.03.2020 um 20:00 schrieb Mikel Maron:
>>   But this thread is from Facebook trying to change that. To side step 
>> imports.
> No they're not. It's a couple sections in a blog post that is being wildly 
> misinterpreted.

Today's blog posts are the press releases of past years. It would have
been quite possible to run it past the responsible organs of the
organisation they were writing about, as it would have been customary in
earlier days.

Simon

>
> * Mikel Maron * +14152835207 @mikel s:mikelmaron
>
>
>
>
>
>
> On Friday, March 20, 2020, 02:18:54 PM EDT, Rory McCann 
>  wrote: 
>
>
>
>
>
> On 19/03/2020 20:15, Mikel Maron wrote:
>
>> This whole thread is blown out of proportion, and rehashing old 
>> theoretical debates about imports that are more or less resolved in 
>> practice.
>
> Yes, we have an import guideline. But this thread is from Facebook 
> trying to change that. To side step imports.
>
> BTW the Etiqutte guidelines require you to assume all people here are 
> operating in good faith 😉
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk



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

Re: [OSM-talk] #AttributionIsNotOptional experiment on OSM France tile servers

[Simon Poole]

Am 12.03.2020 um 16:06 schrieb THEVENON Julien:
> Le jeudi 12 mars 2020 à 15:43:17 UTC+1, Simon Poole  a écrit 
> : 
>
>> To use a completely different example: assume that you purchase a TV set 
>> paid by monthly instalments and you default on them. In civilised countries 
>> that doesn't give the seller the right to break in to your apartment and 
>> repossess the TV, they don't get to cut off electricity to the flat and they 
>> don't get the right to stick big notices on your doors. The seller needs to 
>> utilize the  whatever tools are provided by the legal system, totally 
>> regardless off how upset they are and how righteous they might feel about 
>> their actions.
> Hi Simon,
>
> My internet access provider provide IP TV. If I`m late to pay my TV display a 
> message saying I cannot look at stream until my debt is payed and this is 
> perfectly legal even it targets me precisely.
> My Internet access provider don't break into my appartment neither modify my 
> TV, this is just the stream it sent to me.
> In the case that interest us this is the stream of tile that is modified in 
> the same way except this is due to a non-respect of license instead of a debt.

-that- is not what is analogous to what we are discussing, it would be
more like displaying the message that you are late with the payment on
every TV in the country.

Simon

> Best regards
> Julien
>



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

Re: [OSM-talk] #AttributionIsNotOptional experiment on OSM France tile servers

[Simon Poole]

Am 12.03.2020 um 15:56 schrieb Pierre Béland:
> Mar. 12 2020 10 h 43 min  UTC−4, Simon Poole wrote :
>
> > To use a completely different example: assume that you purchase
> a TV set paid by monthly instalments and you default on them. In
> civilised countries that doesn't give the seller the right to break in
> to your apartment and repossess the TV, they don't get to cut off
> electricity to the flat and they don't get the right to stick big
> notices on your doors. The seller needs to utilize the  whatever
> tools are provided by the legal system, totally regardless off how
> upset they are and how righteous they might feel about their actions.
> Simon
>
> An other example
> Let say we produce bricks standing outside of the shop.  Since too
> many are stolen, we use a trick to make the bricks flashing with a
> message when they get in inappropriate hands. Can somebody sue us
> because their house is flashing with message about where the bricks
> come from ?

Breach of a contract is not the same as stealing goods*, but depending
on legislation you could very well get sued for disclosing the alleged
criminals name.

Simon

* in IP legislation things are not quite so clear but that is really
going too far now.



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

Re: [OSM-talk] #AttributionIsNotOptional experiment on OSM France tile servers

[Simon Poole]

The process of

- creating a list of sites that you want to target

- creating a message and designing a method to display it on the 3rd
parties website

is very much deliberately scribbling on the third parties website.

To use a completely different example: assume that you purchase a TV set
paid by monthly instalments and you default on them. In civilised
countries that doesn't give the seller the right to break in to your
apartment and repossess the TV, they don't get to cut off electricity to
the flat and they don't get the right to stick big notices on your
doors. The seller needs to utilize the  whatever tools are provided by
the legal system, totally regardless off how upset they are and how
righteous they might feel about their actions.

Simon

Am 12.03.2020 um 15:09 schrieb Martin Koppenhoefer:
> Am Do., 12. März 2020 um 11:50 Uhr schrieb Simon Poole  <mailto:si...@poole.ch>>:
>
> So say you scribble on a German companies website,
>
>
>
> I am not talking about "scribbling" on someone else's website. The
> case at hand is about a specific website infringing attribution
> requirements and as a result they themselves integrating tiles (from
> the French tileserver) which makes people aware that they are
> infringing. "Scribbling" on someone else's homepage is very different
> to changing the addresses of images / renaming files on your own
> webserver.
>
> Cheers
> Martin
>


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

Re: [OSM-talk] #AttributionIsNotOptional experiment on OSM France tile servers

[Simon Poole]

Am 12.03.2020 um 10:58 schrieb Martin Koppenhoefer:
> Am Mi., 11. März 2020 um 17:21 Uhr schrieb Simon Poole  <mailto:si...@poole.ch>>:
>
> I would be very very wary of doing anything that deliberately
> defaces a web site without consulting with a local (to the country
> the web site is in) lawyer, particularly if the message implies
> wrong doing."
>
> As I am not a lawyer in any country that a website could be
> displayed in, I'm really the wrong person to ask.
>
>
> So with "local lawyer" you were aiming at the country where the
> website could be displayed in? From my understanding, these local laws
> of the enduser only might matter for the service provider who uses the
> map tiles, while for the service that provides the map tiles (assuming
> reasonable ToS) their own local law would be the only relevant,
> especially when we are talking about B2B?

The "web site is in" should have been "the country the
business/organisation has its place of business in", as clarification,
but not excluding countries where they might not have a domicile but do
business in.

So say you scribble on a German companies website, if they are feeling
in the mood, you could be sued at least based on "Recht am
eingerichteten und ausgeübten Gewerbebetrieb" for damages (and naturally
to cease doing it)*. I suspect that you would not be able to reflect
this with terms in your ToUs, but as said you need to consult with
counsel in the know to be ale to asses the ricks of that happening.

Simon

*just in case you believe I'm just making things up: I was sued two
decades ago as a CEO of company on that base just for stating in a press
release that we intended to start providing services in Germany in the
foreseeable future and having a website that was accessible there. The
underlying problem was a  name and trademark conflict with a German
company of the same name (different area of business though). The net
result after multiple 10'000 of Euros of court, damages and lawyer
costs, not to mention renaming the company, all products and so on, is
that I still have a multiple 100'000 Euro per infringement injunction
against me personally in that matter. And that was a case in which we
were not clearly doing something that was wrong,  very different than
what we are discussing here.



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

Re: [OSM-talk] #AttributionIsNotOptional experiment on OSM France tile servers

[Simon Poole]

Well the other bit that I wrote was:

"Enforcing attribution for services that you are providing directly (aka
tiles in some form) only has a small overlap with the goals of the
attribution guideline, and the avenues open to you depend on your ToUs /
contracts with your users and the legal situation in the countries you
are providing the service in.

I would be very very wary of doing anything that deliberately defaces a
web site without consulting with a local (to the country the web site is
in) lawyer, particularly if the message implies wrong doing."

As I am not a lawyer in any country that a website could be displayed
in, I'm really the wrong person to ask. Things vary widely by country,
that is in particular: inclination and costs to sue and protection
afforded to buisiness undertakings. But it is clear that using a neutral
message and clear ToUs, is definitely less risky than an aggressive
message without ToUs.

Things that need to be considered:

- any message you display will be shown to customers / users of the site
in question and needs to toned down enough so that you don't cause
unwarranted damage to the reputation of the sites operators. It is
likely that if you get sued that the range of options for action
available to you will be considered, you will need to show that what you
did was appropriate.

- everybody makes mistakes, so you -will- miss existing attribution.
Anything you do needs to be able to be undone with a simple "sorry it
was a mistake", except if you have deep pockets.

I'm very aware that getting peoples attention is sometimes difficult,
from experience things that work: sending a fax, registered mail, phone
calls,worst case publicly messaging on social media.

Simon


Am 11.03.2020 um 16:17 schrieb joost schouppe:
> Hi Simon,
>
> In a volunteer community, fun things are more likely to happen at all.
> So I do think the idea is worth exploring, even if the current
> implementation might be risky to OSMfr or to OSMF if implemented
> without much further thought.
>
> I would personally be interested in a more in depth analysis from you.
> I personally don't see how a more neutral message ("This map is based
> on OpenStreetMap data. Please add the required attribution to your
> website. Contact us at X if you need help.") would be more defacing or
> likely to lead to a liability claim than just a blacked out map, but I
> would not mind at all to be enlightened.
>
> Joost
>
> Op wo 11 mrt. 2020 om 15:39 schreef Simon Poole  <mailto:si...@poole.ch>>:
>
> As I wrote (conveniently ignored in the noise of the vigilante
> rampage): "The safe, I admit also the less fun, option, is to
> simply block access after giving any required notice."
>
> Simon
>
> Am 11.03.2020 um 14:49 schrieb joost schouppe:
>> Simon,
>>
>> I guess with small overlap you mean it's only about people who
>> use osm.org <http://osm.org> tiles, not people who use other
>> services?
>> While that is true, the double whammy of both heavily using
>> resources and also not attributing does seem like a good subgroup
>> to start with some measures.
>>
>> In the case of the OSM.org tiles, I suppose this is regulated by
>> https://wiki.osmfoundation.org/wiki/Terms_of_Use . At first
>> glance I didn't see anything providing people who do not respect
>> those terms. Am I missing something, or is this a naive approach
>> to the problem?
>> Even if the ToU's could be lacking in detail, couldn't we simply
>> change them? The final section talks about changes, which we seem
>> to be able to just do when we want to.
>>
>> I would think the biggest challenge on OSMF side would be the
>> workload for OWG/sysadmins.
>>
>> Best,
>> Joost
>>
>> Op zo 8 mrt. 2020 om 12:18 schreef Simon Poole > <mailto:si...@poole.ch>>:
>>
>> Just for the record:
>>
>> Enforcing attribution for services that you are providing
>> directly (aka tiles in some form) only has a small overlap
>> with the goals of the attribution guideline, and the avenues
>> open to you depend on your ToUs / contracts with your users
>> and the legal situation in the countries you are providing
>> the service in.
>>
>> I would be very very wary of doing anything that deliberately
>> defaces a web site without consulting with a local (to the
>> country the web site is in) lawyer, particularly if the
>> message implies wrong doing. The safe, I admit also the less
>>  

Re: [OSM-talk] #AttributionIsNotOptional experiment on OSM France tile servers

[Simon Poole]

Am 11.03.2020 um 15:48 schrieb Mateusz Konieczny via talk:
> Mar 11, 2020, 15:37 by si...@poole.ch:
>
> As I wrote (conveniently ignored in the noise of the vigilante
> rampage): "
>
> I guess that people were irritated by describing gentle reminder about
> license requirements
> using pejorative terms ("deface") where their applicability was dubious.
Sorry, but that is exactly the appropriate term, and anything that will
inevitably get you on the wrong end of being sued if you do it often
enough, is not a "gentle reminder".
>
> The safe, I admit also the less fun, option, is to simply block
> access after giving any required notice."
>
> And note that in case of OSMF-served tiles no notice is required.
>
I'm not sure why you feel it necessary to tell me about terms that I'm
completely aware off (and in some cases that I actually co-wrote), the
subject matter in this thread is not -just- about the OSMF operated
servers, but of those of OSM-FR and others.

Simon

> See https://operations.osmfoundation.org/policies/tiles/
>
> "Clearly display license attribution." is in explicit requirements,
> and given overloaded servers
>
> "should any users or patterns of usage nevertheless cause problems to
> the service, access may still be blocked without prior notice."
>
> applies anyway.
>
> "access may be withdrawn at any point" is later repeated.
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk


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

Re: [OSM-talk] #AttributionIsNotOptional experiment on OSM France tile servers

[Simon Poole]

As I wrote (conveniently ignored in the noise of the vigilante rampage):
"The safe, I admit also the less fun, option, is to simply block access
after giving any required notice."

Simon

Am 11.03.2020 um 14:49 schrieb joost schouppe:
> Simon,
>
> I guess with small overlap you mean it's only about people who use
> osm.org <http://osm.org> tiles, not people who use other services?
> While that is true, the double whammy of both heavily using resources
> and also not attributing does seem like a good subgroup to start with
> some measures.
>
> In the case of the OSM.org tiles, I suppose this is regulated by
> https://wiki.osmfoundation.org/wiki/Terms_of_Use . At first glance I
> didn't see anything providing people who do not respect those terms.
> Am I missing something, or is this a naive approach to the problem?
> Even if the ToU's could be lacking in detail, couldn't we simply
> change them? The final section talks about changes, which we seem to
> be able to just do when we want to.
>
> I would think the biggest challenge on OSMF side would be the workload
> for OWG/sysadmins.
>
> Best,
> Joost
>
> Op zo 8 mrt. 2020 om 12:18 schreef Simon Poole  <mailto:si...@poole.ch>>:
>
> Just for the record:
>
> Enforcing attribution for services that you are providing directly
> (aka tiles in some form) only has a small overlap with the goals
> of the attribution guideline, and the avenues open to you depend
> on your ToUs / contracts with your users and the legal situation
> in the countries you are providing the service in.
>
> I would be very very wary of doing anything that deliberately
> defaces a web site without consulting with a local (to the country
> the web site is in) lawyer, particularly if the message implies
> wrong doing. The safe, I admit also the less fun, option, is to
> simply block access after giving any required notice.
>
> Simon 
>
> Am 08.03.2020 um 11:04 schrieb Yves:
>> This looks at first as a nuisance that could be perceived as a
>> bad move, but the feedback you're receiving rather prove the
>> contrary.
>> Well done!
>> Ps: would you share your nginx partial redirect, I may consider
>> it for Opensnowmap tiles policy?
>>
>> Le 8 mars 2020 10:14:58 GMT+01:00, Christian Quest
>>  <mailto:cqu...@openstreetmap.fr> a écrit :
>>
>> Here is a hort report on this experiment...
>>
>> I started a week ago by searching OSM France tile server logs
>> for referer and checked manually if the map on the refering
>> page was correctly attributed.
>>
>> This allowed me to create a short list of 20 entries of sites
>> using the french styled tiles and the humanitarian tiles
>> (yes, it is made by OSM France).
>>
>>
>> I then modified our nginx based proxy_cache configuration, to
>> redirect some tiles to an "attribution tile" only for the
>> domain in the list.
>>
>> For two of them, I tweeted about it... the most visible one
>> is the moroco yellow page service, generating a little less
>> than a million daily tile requests on our servers.
>>
>> https://twitter.com/cq94/status/1234516075695525888
>>
>> In less than 24 hours, the attribution appeared and I removed
>> them from the list.
>>
>> https://twitter.com/cq94/status/1234779931537739776
>>
>>
>> Then I included an email address in the attribution reminder
>> tile... and got emails back within a few hours.
>>
>> Some were asking how to do the attribution, others telling me
>> the attribution was now ok and asking how to remove the
>> reminder tiles.
>>
>> In my answers, I also remind that our tile service made by
>> volunteers on donated hardware is not unlimited and inviting
>> them to have a look at switch2osm to setup their own tile
>> server or use a commercial provider.
>>
>> Up to now, nobody complained :)
>>
>>
>> Yesterday, I've started automating attribution checking using
>> selenium. For each referer, a python script loads the page,
>> searches for tiles, then looks for attribution text or link.
>> The result is stored in a postgresql database which allows to
>> group referers by url, hostname and ip.
>>
>> The attribution percentage I currently see is a

Re: [OSM-talk] #AttributionIsNotOptional experiment on OSM France tile servers

[Simon Poole]

Just for the record:

Enforcing attribution for services that you are providing directly (aka
tiles in some form) only has a small overlap with the goals of the
attribution guideline, and the avenues open to you depend on your ToUs /
contracts with your users and the legal situation in the countries you
are providing the service in.

I would be very very wary of doing anything that deliberately defaces a
web site without consulting with a local (to the country the web site is
in) lawyer, particularly if the message implies wrong doing. The safe, I
admit also the less fun, option, is to simply block access after giving
any required notice.

Simon 

Am 08.03.2020 um 11:04 schrieb Yves:
> This looks at first as a nuisance that could be perceived as a bad
> move, but the feedback you're receiving rather prove the contrary.
> Well done!
> Ps: would you share your nginx partial redirect, I may consider it for
> Opensnowmap tiles policy?
>
> Le 8 mars 2020 10:14:58 GMT+01:00, Christian Quest
>  a écrit :
>
> Here is a hort report on this experiment...
>
> I started a week ago by searching OSM France tile server logs for
> referer and checked manually if the map on the refering page was
> correctly attributed.
>
> This allowed me to create a short list of 20 entries of sites
> using the french styled tiles and the humanitarian tiles (yes, it
> is made by OSM France).
>
>
> I then modified our nginx based proxy_cache configuration, to
> redirect some tiles to an "attribution tile" only for the domain
> in the list.
>
> For two of them, I tweeted about it... the most visible one is the
> moroco yellow page service, generating a little less than a
> million daily tile requests on our servers.
>
> https://twitter.com/cq94/status/1234516075695525888
>
> In less than 24 hours, the attribution appeared and I removed them
> from the list.
>
> https://twitter.com/cq94/status/1234779931537739776
>
>
> Then I included an email address in the attribution reminder
> tile... and got emails back within a few hours.
>
> Some were asking how to do the attribution, others telling me the
> attribution was now ok and asking how to remove the reminder tiles.
>
> In my answers, I also remind that our tile service made by
> volunteers on donated hardware is not unlimited and inviting them
> to have a look at switch2osm to setup their own tile server or use
> a commercial provider.
>
> Up to now, nobody complained :)
>
>
> Yesterday, I've started automating attribution checking using
> selenium. For each referer, a python script loads the page,
> searches for tiles, then looks for attribution text or link. The
> result is stored in a postgresql database which allows to group
> referers by url, hostname and ip.
>
> The attribution percentage I currently see is around 70-80% which
> is not that bad.
>
> My next major step is to use the same technique to remind about
> tile usage policy...
>
>
> To do something similar on osm.org, a first step is to extract
> referers from the cache logs, then use the automated attribution
> check to evaluate the situation.
>
>
> Le 08/03/2020 à 01:52, Nuno Caldeira a écrit :
>> That would be a good option for those that use third party
>> providers of OSM. But to be honest, from my experience I highly
>> doubt that even corporate members of OSMF, like Mapbox would do
>> it, when their client Facebook (also corporate member of OSMF)
>> after one year and half, still has maps with lack of attribution
>> or attributed to HERE, when it's clearly OSM. 
>>
>> On Sun, 8 Mar 2020, 00:46 Phil Wyatt, > <mailto:p...@wyatt-family.com>> wrote:
>>
>> I am sure others may have seen this 'blacklist'
>> implementation for showing a reminder about attribution.
>>
>> https://twitter.com/cq94/status/1234528717604577282
>>
>> Worthy of consideration for openstreetmap.org
>> <http://openstreetmap.org>?
>>
>> Cheers - Phil
>>
> -- 
> Christian Quest - OpenStreetMap France
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk


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

Re: [OSM-talk] Is there some existing detailed tutorial directed at complete newbies? Describing how to add various features?

[Simon Poole]

From a pedagogic point of view I would consider that suboptimal, no to
mention that it would be endless.

For anybody that is going to contribute more than once (and iDs tutorial
does a good job of guiding through that), we want them to learn the
basic concepts of OSM and enable them to extend that to new situations.

That is different from a guided contribution model, say for example with
https://osmybiz.osm.ch/ <https://osmybiz.osm.ch/#/19/47.15976/8.36968>
which is preferable for people that don't want to contribute to OSM in
general but just want to add and maintain a specific object.

Simon

Am 22.02.2020 um 05:37 schrieb Mateusz Konieczny via talk:
> Is there some automatically generated website
> describing in excruciating detail how to map various features?
>
> Something directed to a potential mappers,
> explicitly describing every single smallest step,
> for every single mappable feature.
>
> I ask as I had again a friend asking me
> "how to add aconstruction area/path/... to OSM".
>
> And it seems to me that automatically generated
> set of such tutorials is both feasible and potentially useful.
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk


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

Re: [OSM-talk] Attribution guideline update

[Simon Poole]

Am 19.02.2020 um 14:24 schrieb Christoph Hormann:
> In this case the statement that "small maps or multiple data sources" 
> are the only cases where the document does not require visible 
> attribution is wrong.  For example it is later stated that visible 
> attribution is not required if "there is legal or safety or privacy 
> information that needs to be presented with similar or greater 
> prominence to attribution" - which at least in the EU is always the 
> case!

So you agree with us that this is an actual external restraint that
needs to be considered, and it is not the LWG succumbing to the
interests of big $$$?




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

Re: [OSM-talk] Attribution guideline update

[Simon Poole]

Am 20.02.2020 um 11:34 schrieb Christoph Hormann:
> What you don't seem to understand is that there is nothing in the ODbL 
> that allows the conclusion that for OSM data use on certain devices 
> there is a *lesser* requirement for making the user aware of the use of 
> OSM data than on others (based on physical size or other factors).
>
> So the recommendation for small devices can and should only be that if a 
> data user uses OSM data under conditions where the usual attribution is 
> technically not possible or economically not desirable they have to 
> choose a different form that has *an equal or larger likeliness of 
> making the user aware of the OSM data use*.

The ODbL requires the attribution to be "reasonably calculated ...",
which includes, naturally, "where the user would typically expect to
find attribution". That can, and will differ based on the actual device
displaying it. There is no requirement in the ODbL that all devices need
to be treated equally or the same.




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

Re: [OSM-talk] Attribution guideline update

[Simon Poole]

Am 20.02.2020 um 11:19 schrieb Christian Quest:
>
> - the 10.000m2 limit, this is completely artificial
>
>
Artificial "yes", but the main thing is that it is small enough to
ensure that it will essentially never be a substantial extract, on the
other hand large enough that you can cover the location of your
entrance, parking lot or whatever in it, with other words, large enough
to be useful.



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

Re: [OSM-talk] Attribution guideline update

[Simon Poole]

Folks, I was being a bit tongue in cheek, obviously the point didn't get
across. I apologize and re-state:

For many legal and marketing reasons providing attribution to "OSM" is
not something that is likely ever going to be supported or recommended
by the OSMF as sufficient.

This is nothing new and has nothing to do with the proposed guideline
outside of reducing the options.

Simon

Am 20.02.2020 um 00:44 schrieb Mateusz Konieczny via talk:
>
>
>
> 19 Feb 2020, 21:05 by si...@poole.ch:
>
>
> Am 19.02.2020 um 20:17 schrieb Mateusz Konieczny via talk:
>> 19 Feb 2020, 17:22 by dieterdre...@gmail.com
>> <mailto:dieterdre...@gmail.com>:
>>
>> But I stick to the comment that 500px are far too many (=1000
>> actual retina pixels or 1500 px on a retina@3). 
>>
>> Yes, you may easily fit at least "© OSM"
>> with link in such space.
>
> Just that people don't get the wrong idea, using attributing to
> OSM is completely out of the question, since when does Online
> Soccer Manager distribute geo-data?
>
> Obviously, it is only ok when you are constrained 
> for space and there is actually no
> space for longer text.
>
> If you have let's say 450 pixels then you
> should use full name OpenStreetMap.
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk


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

Re: [OSM-talk] Attribution guideline update

[Simon Poole]

Am 19.02.2020 um 20:17 schrieb Mateusz Konieczny via talk:
> 19 Feb 2020, 17:22 by dieterdre...@gmail.com:
>
> But I stick to the comment that 500px are far too many (=1000
> actual retina pixels or 1500 px on a retina@3). 
>
> Yes, you may easily fit at least "© OSM"
> with link in such space.

Just that people don't get the wrong idea, using attributing to OSM is
completely out of the question, since when does Online Soccer Manager
distribute geo-data?

Simon

PS: the 1st part was actually serious.

>
> Suggesting that real attribution is 
> not required in such case is absurd
> and dangerous misrepresentation
> of the ODBL.
>
> ODBL requires attribution clear to
> users of data, there is no waiver for mobile devices.
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk


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

Re: [OSM-talk] Attribution guideline update

[Simon Poole]

I believe there is actually a small issue with the definition here, as
there are two conflicting DIP definitions in use (one pixel on mobile
devices ~160 DPI vs one pixel for CSS 96 DPI), we need to state what we
are using.

Simon

Am 19.02.2020 um 17:22 schrieb Martin Koppenhoefer:
>
> sent from a phone
>
>> Il giorno 19 feb 2020, alle ore 16:37, Michal Migurski  ha 
>> scritto:
>>
>> For our purposes, this is a better definition because it’s defined in terms 
>> of what a viewer can see rather than its implementation in hardware.
>
> contrary to what I had written above I agree that the requirement/definition 
> should be based on css-pixels because actual pixels are hard to know/control 
> (if you design a website you cannot control/forsee the devices that people 
> use to look at it, you base your layout on these theoretical css-pixels). 
> But I stick to the comment that 500px are far too many (=1000 actual retina 
> pixels or 1500 px on a retina@3). 200px seems perfectly ok for rendering a 
> readable attribution string and still having some space left. There is no 
> technical problem with lack of space for 200px wide maps.
>
> Cheers Martin 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk



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

Re: [OSM-talk] Attribution guideline update

[Simon Poole]

Am 19.02.2020 um 15:59 schrieb Martin Koppenhoefer:
> ..
> Imho we should not differentiate between mobile and desktop devices:
> either there is sufficient space and attribution should be permanent,
> or there isn’t and it is ok you have to click somewhere to see it. The
> constraints/conditions for being sufficient space are the same on
> mobile devices and other devices.
> ...


As pointed out in the guideline text, the difference is not only screen
size, but how you interact with the device. Try clicking on your average
watch.



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

Re: [OSM-talk] Attribution guideline update

[Simon Poole]

There is a difference (a very big one), between saying "if you do X we
believe you are fulfilling the requirements of the licence" and saying
"you need to do Y to make us happy, even if it doesn't have any founding
in the licence". And that has nothing to do with winning court cases,
but all with staying true to the 6 million plus agreements the OSMF has
with OSM contributors, or put differently: behaving ethically ourselves.

Simon

Am 19.02.2020 um 15:51 schrieb Joseph Eisenberg:
> If the map says "Copyright BoxMap, imagery copyright IRSE" in bold in
> the right corner, but the Openstreetmap notice is hidden behind a tiny
> "i" or ony shown briefly on app startup (which only happens after your
> phone crashes or the app updates), then this gives the impression that
> the data is also from BoxMap and IRSE. That is false attribution.
>
>>  "we are only saying that if you follow the guidleine we believe you are 
>> providing sufficient attribution as required by the licence"
> Right, and this is our guideline which means "we won't sue you if you
> follow these steps." It is perfectly reasonable to request things that
> are the ethical and common-sensically "right way to do it" even if we
> can't win a court verdict in London or New York or wherever. As the
> guideline states, we are not claiming to have determined the legal
> status in any particular country.
>
> There is nothing wrong about requesting specific attribution details
> which are not mentioned in the license. You certainly know that the
> guidelines are much more specific than the license already, mainly in
> the many exceptions to the normal attribution requirements which the
> draft is allowing. We can also add more specific requirements and
> trust that most database users will do their best to follow them.
>
>> I would suggest reading https://sfconservancy.org/blog/?author=bkuhn "Toward 
>> Copyleft Equality for All".
> That article is unintelligible to me. Too many jargon terms. But I
> will note that "Slippery slope" is a logical fallacy, whether you use
> it to argue for stronger or weaker license enforcement and terms.
> https://yourlogicalfallacyis.com/slippery-slope
>
> - Joseph Eisenberg
>
> On 2/19/20, Simon Poole  wrote:
>> Am 19.02.2020 um 14:40 schrieb Joseph Eisenberg:
>>>> IMHO attribution should always be required  1. on the map 2. in high
>>>> contrast
>>> Agreed.
>>>
>>> The main problem is that mobile devices, which are by far the most
>>> common ways of accessing maps around the world, are only required to
>>> provide attribution after a click or swipe, or even just on app
>>> startup with a short "splash" screen:
>> Providing attribution on splash screen is an obvious and widely accepted
>> way of attribution completely independently of the guideline we are
>> discussing here.
>>> I think there should be a statement in the guideline that
>>> Openstreetmap attribution must not be inferior to attribution of other
>>> data sources or the map designer. That is, if the app logo or aerial
>>> imagery copyright is shown, then Openstreetmap must also be shown at
>>> the same time. If Openstreetmap is relegated to a separate splash page
>>> or linked page, the other copyright/logo features must also be on that
>>> page.
>> The licence does not stipulate any relative criteria for attribution wrt
>> UI elements, other attribution or anything else on the screen. Adding
>> such a requirement would break the open definitions requirement that all
>> terms for use of the content be defined in the licence. Obviously there
>> is a fine line there that we try not to cross with this guideline, in
>> that we are only saying that if you follow the guidleine we believe you
>> are providing sufficient attribution as required by the licence (note
>> this not new, the problem is inherent in giving any guidance wrt any
>> effect of the licence).
>>
>>> We should not give up on enforcing basic ethical behavior from
>>> corporations. Everyone who has been to school knows that copying
>>> without attribution is plagarism, and putting your logo on the front
>>> makes it look like plagarism if Openstreetmap is relegated to a
>>> non-visible page.
>> Again, enforcing ethical behaviour is outside of the scope of open data
>> licensing, at least in the definition that is used in our contributor
>> terms (and which in practical terms is immutable).
>>
>> There is currently a lot of discussion on this topic in the OSS
>> commun

Re: [OSM-talk] Attribution guideline update

[Simon Poole]

Am 19.02.2020 um 15:02 schrieb Frederik Ramm:
>
> In my mind I always ask the question: How essential was OSM for what is
> being done? How much of your hike remains if you remove OSM from the
> picture? How much of a trained AI remains if you remove OSM from the
> picture?

Assuming "essential" doesn't mean "can't be replaced by a different
product", obviously in both cases nothing remains.

SImon




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

Re: [OSM-talk] Attribution guideline update

[Simon Poole]

Am 19.02.2020 um 14:40 schrieb Joseph Eisenberg:
>> IMHO attribution should always be required  1. on the map 2. in high contrast
> Agreed.
>
> The main problem is that mobile devices, which are by far the most
> common ways of accessing maps around the world, are only required to
> provide attribution after a click or swipe, or even just on app
> startup with a short "splash" screen:
Providing attribution on splash screen is an obvious and widely accepted
way of attribution completely independently of the guideline we are
discussing here.
>
> I think there should be a statement in the guideline that
> Openstreetmap attribution must not be inferior to attribution of other
> data sources or the map designer. That is, if the app logo or aerial
> imagery copyright is shown, then Openstreetmap must also be shown at
> the same time. If Openstreetmap is relegated to a separate splash page
> or linked page, the other copyright/logo features must also be on that
> page.

The licence does not stipulate any relative criteria for attribution wrt
UI elements, other attribution or anything else on the screen. Adding
such a requirement would break the open definitions requirement that all
terms for use of the content be defined in the licence. Obviously there
is a fine line there that we try not to cross with this guideline, in
that we are only saying that if you follow the guidleine we believe you
are providing sufficient attribution as required by the licence (note
this not new, the problem is inherent in giving any guidance wrt any
effect of the licence).   

> We should not give up on enforcing basic ethical behavior from
> corporations. Everyone who has been to school knows that copying
> without attribution is plagarism, and putting your logo on the front
> makes it look like plagarism if Openstreetmap is relegated to a
> non-visible page.

Again, enforcing ethical behaviour is outside of the scope of open data
licensing, at least in the definition that is used in our contributor
terms (and which in practical terms is immutable).

There is currently a lot of discussion on this topic in the OSS
communities, but just to illustrate the kind of slippery slope you are
venturing on to, I would suggest reading
https://sfconservancy.org/blog/?author=bkuhn "Toward Copyleft Equality
for All".

Simon

>
> - Joseph M Eisenberg
> (Hobbiest mapper from USA in Indonesia, volunteer contributor to the
> Openstreetmap Carto map style. I have no financial or professional
> interest or conflict.)
>
> On 2/19/20, Martin Koppenhoefer  wrote:
>> Am Mi., 19. Feb. 2020 um 13:53 Uhr schrieb Frederik Ramm <
>> frede...@remote.org>:
>>
>>>> Not to mention the most blatant attempts at sneaking corporate wishlist
>>>> items into the guideline are all still there - like the 1 m^2 map
>>>> area limit that has been conjured out of thin air
>>> True, this is a bit strange, it would have to be replaced by "an area of
>>> up to 1,000 inhabitants" as per the "Substantial" guideline - though I
>>> don't find the difference outrageous, in fact the 10.000m² will only be
>>> *friendlier* towards non-attribution than the "1.000 inhabitatants" in
>>> densely populated urban areas.
>>
>>
>> I guess 10k sqm will be a stronger requirement (almost) everywhere, for
>> example look at Manhattan, maybe not the densest place on earth, but surely
>> one of the densers. With roughly 27500 inhabitants per sqkm, on the average
>> 100x100m NYC patch there will only be 275 inhabitants.
>>
>>
>>
>> I stumbled upon the small maps section.
>> __
>> The following maps are each considered small:
>>
>>- The map takes up less than 25% of the displayed window, or
>>- The map is of less than 500 device-independent pixels horizontally.
>>
>> Small maps may have attribution after one interaction. Examples of one
>> interaction include “one click,” such as an icon or link that opens a
>> pop-up or new webpage that displays attribution, or a mouseover, swipe,
>> drag, pinch, etc.
>> __
>>
>> Isn't the reason for not requiring attribution _on the map_ the limited
>> space? Why is there a condition that makes (easily visible) attribution not
>> mandatory for extremely large screens? There is a development from several
>> screens to large screens, and pixel density is generally growing, so the
>> "max 25% of the displayed window is a map" condition doesn't seem
>> reasonable. IMHO attribution should always be required
>>
>> 1. on the map
>> 2. in high contrast
>>
>> (3. in a lower corner, left or right)
>>
>&

Re: [OSM-talk] Attribution guideline update

[Simon Poole]

Am 19.02.2020 um 13:50 schrieb Frederik Ramm:
> ...
> I acknowledge Kathleen Lu's recent remark about the ODbL being very
> clear on a derived product having to "contain" OSM in some way which
> would not be the case here; but I think this calls for working on ODbL
> 1.1 to rectify the issue, rather than sitting back and saying "uh, guess
> there's nothing we can do then".
> ...

IMHO the issue here is that we often, mistakenly, tend to treat "using"
OSM the same as "creating a derivative of OSM data".

As a thought experiment consider planning a trip around your fav place
boundary with OSM,  going for the walk with an OSM based map in your
hand so that you stay on course, and then writing a a blog post about
your experience. For the purpose of the argument forget about
substantial vs. non-substantial and Produced Works vs. Derivative Databases.

Is the blog post a derivative of OSM?

Simon





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

[OSM-talk] Attribution guideline update

[Simon Poole]

The LWG has now integrated feedback from the initial airing in August
last year, from a total of three sessions at SOTM-US and SOTM in
Heidelberg, feedback from the OSMF board and from the wider OSM community.

Barring any major late developing issues, we intend to forward this to
the OSMF board for formal approval at the next LWG meeting on the 12th
of March. If you have any comments please feel free to add them to the
wikis talk page.

The updated document can be found here
https://wiki.openstreetmap.org/wiki/Draft_Attribution_Guideline

Simon

PS: please disregard the numbering in the document, that will not be
present on the OSMF wiki.




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

Re: [OSM-talk] For the sake of peace | Re: Cease use of OpenStreetMap/Antifa logo

[Simon Poole]

Am 17.02.2020 um 23:42 schrieb Yves:
> ..
> ... or worse, not using the brand at all on their maps for the same goal! 
> Yves 
>  

Actually no, and I'm fairly sure that is the "BIG MISUNDERSTANDING".

If somebody doesn't provide sufficient attribution that doesn't run
away, and we can, for all practical purposes be arbitrary in how and
when we enforce our licence. Very different with our marks and other IP.

For example it is -very- costly to impossible to stop somebody using a
domain name that is a play on OpenStreetMap once they have registered
the domain or acquired it from a former community project. Standard
example openweathermap, but there are numerous other well known examples.

Simon




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

Re: [OSM-talk] For the sake of peace | Re: Cease use of OpenStreetMap/Antifa logo

[Simon Poole]

In no particular role, specifically no official OSMF one:

Can't we resolve this by moving the logo and potentially other ones to
an explicit category:

"Fun, parody and other, not totally serious, remixes of the OSM logo,
not endorsed by anybody"

With a different hat on: it would be really nice if the community was
equally upset about misusing the OpenStreetMap brand and marks by so
many other organisations with the goal of  profiting from OSMs popularity.

Simon

Am 17.02.2020 um 14:25 schrieb Rory McCann:
> In order to keep the peace, I'll voluntarily delete that image from
> the OSM Wiki (as best I can). But the file is out there in the wild,
> you can't stop the internet.
>
> I am only a random person at a keyboard, I'm too much of a wuss to
> throw stones at cops, I'm not a black block antifa protester! But
> (IMO) there is a problem today with the rise of xenophobia, of
> queerphobia, etc. I made this logo partially for fun, but also one way
> to oppose that hate. To me, it's more than just "for the lulz".
> Perhaps, in my original reply, I appeared too flippant. I make use of
> emoijis to convey tone, which is often lost in text. 🙂 means I want
> to be friendly.
>
> To me, it's obvious that an OSM based logo doesn't mean OSM is 100%
> the same as that thing. If I make an OSM mash up, I can still see you
> as a fellow OSMer even if you don't agree with what that logo
> represents. The existence of an OSM cycling logo doesn't mean all
> OSMers have to be cycling activists! But perhaps that was not
> communicated well. I hope the community can figure out how to make
> that clear.
>
> “Keep politics out of OSM” sounds nice, but I question what “politics”
> means here. It's often used only for feminism/pro-LGBTQ/anti-racism
> (and rarely mentioned when a copyright law changes). I think
> “politics” is too ambiguous to be useful when we talk to each other.
>
> For those who see this logo as an OSM/OSMF endorsement, I'd like to
> see an OSM logo remix which, to them, doesn't imply endorsement, so I
> (and others) can design future logo remixes without implying
> endorsement. I never intended, or what to, imply OSMF endorsement, and
> I would like to know how to avoid that.
>
>
> Let's get back to mapping the world.
>
>
> Rory
>
> On 13/02/2020 23:01, Rory McCann wrote:
>>
>> Hello fellow OSMers! 🙂
>>
>> So this is from me. Last year I made some mashups of the OSM logo. There
>> is often a lot of big business presence at tech/FLOSS conferences now,
>> so I thought “What would be the opposite of that?” I am pretty lefty,
>> and I do like OSM's anarchistic/do-ocracy/flat/non-hierarchical
>> tradition anyway. So I ordered these stickers for a laugh, and they (&
>> the LGBTQ designs) were quite popular.
>>
>> I don't believe it breeches the OSMF Trademark policy. §3.5 allows
>> remixed logos for user group logos. §3.2 & §3.4 allow the use of
>> stickers. (There is plenty of other examples of OSM trademark use BTW
>> 😉) I thought it was clear that it didn't reflect OSMF policy, but I'm
>> sure I can communicate that better, to avoid all doubt. Mea Culpa. §2.2
>> of the Trademark policy does require a more explicit notice, which I've
>> now added to the wiki page. §2.3 says I shouldn't suggest OSMF
>> endorsement, and I don't want to suggest, or imply, OSMF affiliation or
>> endorsement! 🙂 I've added a message the wiki page for that image. Do
>> you think that suffices?
>>
>> Yes, by definition all democratic societies are "anti-fascist", but even
>> I know the logo is more than just "anti-fascist", and...
>> controversial. 🙃
>>
>> _However_ I need to think on this. We have a lot of work to do. We have
>> a whole world to map. I don't want everyone to fight, or external people
>> to get mistaken ideas about OSM. 😞 Someone might have a false idea of
>> one thing, and (falsely) think all of OSM is like that.
>>
>> That can go both ways: Right wing, bigoted, politicians sometimes claim
>> "antifa are violent terrorists" (cf. Trump after the Charlottesville
>> rally). “OSM doesn't have a Code of Conduct, and they just banned the
>> antifa logo saying it's a horrible violent organization!” could make
>> some marginalized groups (falsely) think OSM is full of a certain type
>> of hostile person!
>>
>> As well as OSM being inherently political, "No politics" can (in
>> practice) translate to "Don't act gay, and people are allowed be
>> homophobic to y

Re: [OSM-talk] weeklyOSM #497 2020-01-21-2020-01-27

[Simon Poole]

We are talking literally about a one command "pipeline" that already does 
everything right and consumes 1% of the volume of a weekly download of the 
planet. 

Not to mention that you get a daily (or whatever you want) updated planet out 
of it that contains a defined set of diffs (contrary to the planet dump).

Simon 
-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit Kaiten Mail gesendet.
-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit Kaiten Mail gesendet.
-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit Kaiten Mail gesendet.___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] is OSM a fake map.

[Simon Poole]

A couple of general points first:

- nobody "owns" their OSM data in any larger OSM community your data
will be changed by other mappers, and sometimes they will be wrong and
sometimes you,

- good comments and source tags are your friend, indicating how the data
was sourced is key to enabling other mappers to understanding what you did

In your specific case you should engage with the mapper(s) in question
via changeset comments and try to explain the situation to them. If that
doesn't work out, you can approach the DWG (d...@osmfoundation.org) and
ask them to have a look at the situation. If necessary they will
intervene and try to resolve the issues.

Simon


Am 29.12.2019 um 18:27 schrieb 80hnhtv4agou--- via talk:
> it say in some wiki. to correct what you find wrong on the map,
>  
> not one“other nearby users” is a current mapper, and all edits in a 5
> mile radius are not coming from an on the ground
>  
> mappers in my area but 20 miles + away and are tracing from bing, and
> the images on bing in my local area are from
>  
> 2016 so i do not see how the map locally is true, and it is not easy
> to go and see every thing they have done,
>  
> no car or bike. 
>  
> every thing i do is backed up by me on mapillary, and in traces.
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk


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

Re: [OSM-talk] What does WGS84 mean for openstreetmap these days?

[Simon Poole]

It's not quite the same thing as uncertainty in the datum itself.

Crust movements simply lead to things being somewhere else relative to a
global datum (aka they have moved), so a new measurement of the position
for the same object would return the correct current position and
theoretically if the original position was measured you could simply
apply a translation based on the crust movement to get the correct
current coordinates.

Am 20.12.2019 um 15:36 schrieb Jóhannes Birgir Jensson:
> Well the current issue in Iceland is a error of 50 cm between 1993 and 2016 
> due to crust movements. So it's less than 2 meters but more than one cm. What 
> is your accuracy limit if 2m is just unacceptable but a centimeter is?
>
>
> 19. desember 2019 kl. 17:58, skrifaði "Greg Troxel" :
>
>> Interesting about the datum history. But this is the cm strawman I
>> wasn't talking about, not the 2m issue.
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk



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

Re: [OSM-talk] What does WGS84 mean for openstreetmap these days?

[Simon Poole]

Thus is a slightly tricky subject and it is not going away.

For another aspect of it see
https://www.openstreetmap.org/user/StephaneP/diary/390290

Essentially in some cases we are using imagery that isn't actually using
WGS84 as if it was (fsvo of WGS84 as you correctly point out) and we
currently don't actually have a way to correct this . And yes while
continental shift is for most countries smaller than all the other ones
when adding geometry, for Australia this not necessarily true.

Simon

Am 19.12.2019 um 15:33 schrieb Greg Troxel:
> (This is a long and complicated subject and I am intentionally asking
> only part of the question.)
>
> It's been said from the beginning that coordinates in the openstreetmap
> datbase are in "WGS84".  That more or less meant "what a GPS receiver
> showed", back in the days when GPS was the GNSS system of choice and
> accuracies were low compared to talking about versions of WGS84.
>
> In discussion on the proj list, it seems the consensus view is that
> WGS84 is now a term that refers to any one of the 6 realizations of
> WGS84 over time.  This makes sense when you have data that is merely
> labeled WGS84, without a more specific label such as WGS84(G1762).  This
> means that WGS84 is considered low accuracy (because the original was),
> and thus any transforms involving it are assigned high error values.
>
> This page has a good overview of the various WGS84 realizations and
> their relationship to ITRF realizations:
>
>   https://www.e-education.psu.edu/geog862/node/1804
>
>
> As normal people (or at least normal nerds) get access to more accurate
> positions, this question begins to matter, as in North America positions
> in original WGS84 and modern WGS84 differ by more than a meter.
>
> I should note that now that WGS84 has converged to ITRF, and new ITRF
> realizations seem to be at most cm-level changes from previous ones, I
> do not expect future WGS84 revisions to be signficantly different from
> either the current one.
>
> So, I wonder if we want to change the definition for OSM coordinates
> from "WGS84" to "the realization of WGS84 currently in use by GPS".
> That doesn't change older coordindates (and I am not suggesting any
> automated changes!!!).  But it does give a notion of what coordinates
> should be, both in using them and in producing new ones for editing.  I
> expect that this will have zero practical effect for most people, but
> will allow higher accuracy for those who are into extreme accuracy.
>
>
> postscript:
>
> I am intentionally leaving out of this discussion two more issues (which
> could result in further changes, with much more complexity).  I list
> them so that those with some background in geodesy can begin to ponder,
> and to explain that my stopping at the proposal above was intentional.
>
> 1) WGS84 is a US datum.  BEIDOU, GALILEO, GLONASS use different datums.
>SBAS systems also use different datums -- WAAS seems to give
>coordinates in "ITRF2000 (current epoch)".  It seems most are
>equivalent to some modern ITRF, with possibly differing epochs.
>
> (I will assume for point 2 that there OSM redefines coordinates to be a
> particular ITRF at a particular epoch, probably matching the current
> WGS84.)
>
> 2) ITRF is global, but objects we map are generally crust-fixed on some
> plate.  The US has a (mostly, if you're not in CA) crust-fixed datum,
> NAD83, and other countries do too.  This is particularly acute in
> Australia which is a notably fast-moving country :-) The modern trend is
> for stations to have velocities and not just coordinates.  Over 20
> years, this starts to matter.  Several countries are introducing new
> national datums that are intended to address some of these issues.  I
> don't think it makes sense for OSM to deal with this issue for a few
> years.
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk



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

Re: [OSM-talk] Addressing SIG

[Simon Poole]

Am 08.11.2019 um 13:19 schrieb marc marc:
> Hello,
>
> Simon Poole :
>> The issue with addresses is definitely not due to a lack of tools 
>> for OSM contributors. For example
>> https://regio-osm.de/hausnummerauswertung/anzeige_dynamisch.html?land=Schweiz&lon=8.71423&lat=47.05777&zoom=8&layers=B
> lack of tools not only mean "no tool exist",
> it also means "tool not found for the contributor"
>
> how can the new contributor wishing to add an address find this tool?
> there's no way he'll find it. it's an advanced tool for the 1%
> of the most motivated contributors of for newbie at a mapping party.
> the other clicks on edit or note. it is osm.org's ergonomics it-self 
> and/or the greeting message during registration that must be improved
> so that the new contributor can find the tool best suited to his 
> contribution

That doesn't make the slightest difference, because the only people
adding addresses in any meaningful way are those 1% of contributors.

Just imagine that we increase the number of new OSM contributors by an
order of magnitude, to ~2'000'000 per year, and just as magically we get
them to make the single edit they typically make to be adding an
address, instead of whatever they actually wanted to do. Even then, in
the as good as it gets fantasy scenario, it would only be 20% of the
current run rate. And that in turn is probably an order of magnitude or
so too low for Steve (aka 50 years or so to "complete" world wide coverage).

Simon


> Regards,
> Marc
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk



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

[OSM-talk] vespucci crashes since yesterday

[Simon Poole]

Due to a change in the data format provided by the Osmose API, if you
have Osmose enabled (the default), you will experience a crash when
trying to download an area since yesterday.

While I've built a new version that handles the issue (this is simply a
crash avoidance measure, but doesn't address the issue of unexpected
format changes in general, which naturally shouldn't happen), this will
take a while to be available.

The simple workaround for now, and if you are stuck on an old version of
the app, is to disable Osmose downloads. In older versions this can be
found in the "Advanced Preferences" in current versions in the layer
configuration in the layer dialog.

Sorry for the trouble

Simon




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

Re: [OSM-talk] Addressing SIG

[Simon Poole]

Just as a further data point for the discussion: we are currently adding
roughly 10'000'000 addresses per year relatively constant since 2013,
with some exceptions due to imports (mainly NL in 2014 I believe).




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

Re: [OSM-talk] Addressing SIG

[Simon Poole]

The issue with addresses is definitely not due to a lack of tools for
OSM contributors. For example
https://regio-osm.de/hausnummerauswertung/anzeige_dynamisch.html?land=Schweiz&lon=8.71423&lat=47.05777&zoom=8&layers=B
which covers essentially all the analytics needed for comparison with
open data datasets and that since years (not mention the various address
QA layers available, again since years). On the data entry side there
are good tools both for surveying, import and conflation en masse.

What might be missing is simpler variant of
https://osmybiz.osm.ch/#/18/47.40514/8.40289 (I actually have the domain
addmyaddress.org stashed away somewhere for that), but while it would be
nice to provide a simple facility for people to check and potentially
add their address, it is clear that the targeted long tail is not going
to make a substantial difference in coverage.

So what it really boils down to is grunt work*time (and that is even
true for imports). In Central Europe we are well on the way to
acceptable coverage, given a couple of years more I suspect it will be
really good. Nearly everywhere else (special case the US, and apologies
to all the the exceptions to "nearly everywhere") we are missing
essential metadata that should come first, aka road names and
references, POIs, places and so on, essentially all the stuff that
building doodling and ML doesn't provide, but is essential to actually
having a usable map.

Simon

Am 07.11.2019 um 13:18 schrieb marc marc:
> Hello,
>
>> We've been "addressing the address topic" for more than 
>> 5 years in France with our BANO project.
> and despite the amount of opendata information available, 5 years later,
> there is still a lot of red (missing road name or mismatch between
> osm and opendata).
>
> I agree with the original author: there is a lack of a simple tool
> to contribute more effectively to addresses.
> for example a new contributor has no way to validate the name of a 
> street from the opendata. Osmose and BANO layers are good advanced tools 
> but are not adapted to this kind of beginner audience but also out of 
> their sight.
>
> there is also a lack of awareness that missing addresses are
> a lack of osm compared to some proprietary solutions.
>
> Regards,
> Marc
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk


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

Re: [OSM-talk] Maintaining privacy as a casual mapper

[Simon Poole]

The clause is mainly a consequence of the relevant GDPR rules and at the
time (not sure why we are having this discussion after the fact) we
spent a lot of time investigating what potential routes there could be
to working around this, but nobody came up with a workable solution.

Simon 

Am 05.11.2019 um 10:40 schrieb Maarten Deen:
> On 2019-11-05 10:12, Mateusz Konieczny wrote:
>> 4 Nov 2019, 12:53 by md...@xs4all.nl:
>>
>>> In any case, I see that the "You must be 13 years or older to use
>>> the Services." is still there.
>>>
>>> Really? Someone under 13 can not look at the OSM map? I'm sorry, but
>>> that is completely laughable. And not enforcable at all.
>>
>> It is probably necessary for legal reasons, such requirement is
>> typical in TOUs.
>>
>> Mostly result of COPPA[1] and similar laws. Extreme requirements on
>> providing
>> service to children younger than 13 makes it is easier to ban all
>> children younger than 13
>> from service than comply with them.
>>
>> Especially in cases where children are not very likely to contribute
>
> "Use" in this case is also viewing the website. There is no account
> needed for that and if you want to block this you would need to do age
> verification which is a lot more intrusive than not putting this
> clause in your ToU at all. If people think OSM should be doing this,
> they effectively say that children should not use the internet. That
> may be your choice, but it is just that: a choice. In no way a legal
> requirement.
>
> COPPA does not seem to apply since OSM is not directed to children,
> let alone in commercial ventures. The only possible connection would
> be when children register since you would store information about
> them. That might be a sensible reason to block children from
> registering (I can also see that they probably would not have a
> significant positive contribution to the data), but again, at the
> moment any use of OSM by children is blocked.
>
> Either no thought went into that, or it was thought that throwing a
> wide net would be better "to comply" than no net at all. The same
> thing I argue against with the "lots" comment that started this.
> Better to claim that lots of the things you might do to keep your
> privacy are not allowed according to the ToU than to make clear which
> things exactly are not allowed.
> It looks more like FUD to me at the moment.
>
> Regards,
> Maarten
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk



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

Re: [OSM-talk] Maintaining privacy as a casual mapper

[Simon Poole]

Am 04.11.2019 um 12:57 schrieb Martin Koppenhoefer:
> Am Mo., 4. Nov. 2019 um 12:20 Uhr schrieb Simon Poole  <mailto:si...@poole.ch>>:
>
> https://wiki.osmfoundation.org/wiki/Terms_of_Use#II._Privacy requires
> you to keep your contact information (which is currently your e-mail
> address) current. This is not really new as it was implied by
> doing away
> with anonymous edits in 2007.
>
>
>
> actually only signups as anonymous users were abolished in 2007, who
> already had such an account could use it for a significant time after
> that date (IIRR until 2012 license change).

According to
https://github.com/openstreetmap/openstreetmap-website/commit/4eafa04ff8059f475ebfbec2ced1773a9c8b
anonymous editing definitely went away in 2009.



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

Re: [OSM-talk] Maintaining privacy as a casual mapper

[Simon Poole]

Am 04.11.2019 um 10:03 schrieb Maarten Deen:
> On 2019-11-04 09:28, Simon Poole wrote:
>> Am 03.11.2019 um 23:08 schrieb Martin Koppenhoefer:
>>> ...
>>> it depends from whom you hide, but generally you should not use a
>>> traceable email account if you want to remain anonymous. Using
>>> Google would seem like a total no-go (they are even reserving the
>>> right to read your emails). Use a live distro like tails (tor
>>> browser, spoofs browser a system details, etc. ), do not connect
>>> from your home or someone else’s home or any other places that you
>>> are related to, do not use a third party login but create a new
>>> account for every edit you make and use throw away email addresses
>>> for signup. Use generic user names and email addresses created by a
>>> random string generator, only use the most common tools like iD and
>>> maybe josm, do not use rarely used tags, avoid changeset comments
>>> and other free text fields like description and note.
>>
>> Note, lots of the above would be violations of our ToU, and outside of
>> that, neither desirable nor a good idea.
>
> Lots? Care to elaborate on that? Where are the ToU, is it
> <https://wiki.openstreetmap.org/wiki/Terms_of_Use_-_Discussion_Draft>
> (to which I can have some comments too)?
>
> ..

https://wiki.osmfoundation.org/wiki/Terms_of_Use  and linked to from the
sign up page, and from the map page. There where multiple opportunity
last year to comment on the draft (which has nothing to do with the old
wiki page you linked too), which you seemed to have not used, even
though it was widely announced.


>
> In any case, if the link I posted are the ToU, I don't see any of
> those points being a violation of the ToU. In the case of the account,
> where the ToU says "You represent and warrant that the information you
> provide to OSMF upon registration and, at all other times, will be
> true, accurate, current, and complete" it is an empty point since
> there is no verifiable information I _have_ to enter into my account.
> Just a screen name (not my legal name) and an email address.

https://wiki.osmfoundation.org/wiki/Terms_of_Use#II._Privacy requires
you to keep your contact information (which is currently your e-mail
address) current. This is not really new as it was implied by doing away
with anonymous edits in 2007.

> Further items like my location and a profile description are optional.
>
To be clear certain risk reduction measures are completely OK and we
outline these in the privacy policy, what is not OK is anything that
amounts to de facto making the edits anonymous to the OSMF.

Simon





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

Re: [OSM-talk] Maintaining privacy as a casual mapper

[Simon Poole]

Am 03.11.2019 um 23:08 schrieb Martin Koppenhoefer:
> ...
> it depends from whom you hide, but generally you should not use a traceable 
> email account if you want to remain anonymous. Using Google would seem like a 
> total no-go (they are even reserving the right to read your emails). Use a 
> live distro like tails (tor browser, spoofs browser a system details, etc. ), 
> do not connect from your home or someone else’s home or any other places that 
> you are related to, do not use a third party login but create a new account 
> for every edit you make and use throw away email addresses for signup. Use 
> generic user names and email addresses created by a random string generator, 
> only use the most common tools like iD and maybe josm, do not use rarely used 
> tags, avoid changeset comments and other free text fields like description 
> and note.

Note, lots of the above would be violations of our ToU, and outside of
that, neither desirable nor a good idea.

IRL editing on OSM is very near to publishing a blog post or similar,
something you are doing in public with the intent  of the results being
public and there are limits to how far you can do this in an anonymous
fashion. If you can't live with the resulting consequences I would
suggest not contributing in any larger fashion.




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

Re: [OSM-talk] [Osmf-talk] Attribution guideline status update

[Simon Poole]

The problem with this thread is that it is conflating different (but a
bit related) things.

- missing or less than perfect attribution,

- corporate messaging about OpenStreetMap (or more the lack of it).

As to the first point in general we are just arguing about the form, not
the principle. We have only one case that I'm aware of, in which a
publisher is claiming that they do not need to provide attribution, and
we are pursing that with legal means.

It is however important to realize that their are limits to copyright
and that for example lots of the "non-attribution" in the states is
likely permissible fair use under US laws. It would still be good form
to provide attribution, but it isn't something we can enforce and
getting upset about such use is really just a tremendous waste of time.

As to the 2nd point, yes it might be annoying that we don't get more
positive corporate messaging around the use of OpenStreetMap,
particularly when the companies in question wouldn't actually exist
without OSM, but it isn't a legal or attribution question and should be
kept separate.  Relying on third parties that are mainly beholden to
money to do messaging on our behalf is a very bad idea in any case, the
responsibility for positive messaging is clearly part of the remit of
the OSMF.

Simon

Am 31.10.2019 um 10:41 schrieb Nuno Caldeira:
> do a search for Strava on social media images, on twitter as examples:
>
> https://twitter.com/MissJKirby/status/1189164486252515333?s=09
>
> https://twitter.com/boorapong88/status/1188767309357142016?s=09
>
> https://twitter.com/dai_walters/status/1188488659089141760?s=09
>
> só either everyone crops the image or there's something wrong. 
>
>
> following your mindset, we should blame the map provider (Mapbox) and
> not the company that uses the maos. Does this apply to Facebook too?
> As Mapbox is a corporate member of OSMF and several employees of
> theirs are members of board or working groups, that shouldn't be to
> hard to fix the lack of attribution, right? 
>
> On Thu, 31 Oct 2019, 09:28 Jeffrey Friedl,  <mailto:jfri...@yahoo.com>> wrote:
>
>
>
>
>
>
> > > And the hypocrisy goes on. "Strava launches gorgeous new
> outdoor maps"
> 
> https://blog.mapbox.com/strava-launches-gorgeous-new-outdoor-maps-977c74cf37f9
> >
> >    I'm not sure what you're reporting, but the maps all have "©
> Mapbox © OpenStreetMap" in the lower-left
> >    corner.  (Perhaps they were cut off in some of the
> screenshots in news coverage, but the actual maps in
> >    the Strava app and on their web site all have this
> attribution.)  I suppose that they could use a slightly
> >    stronger background shadow, to create more contrast when the
> map behind the attribution is light.
> >
> >
> > that is not true.
>
> WHAT is not true? Why can't you be specific?
>
> > https://twitter.com/mastermen/status/1127672128797663239?s=09
>
> That's a half year ago, showing an edited screen capture. What
> relevence is to this discussion?
>
> > from the moment they use OSM they agreed with it's terms
>
> "They" being Strava?  I don't beleve that Strava uses, or has ever
> used, OSM data.
> I'm pretty sure that Strava is a customer of Mapbox, and it's
> *Mapbox* that uses OSM data
> and generates images that Strava displays.  If Mapbox is not
> putting attributions properly,
> complain to/about them.
>
>     Jeffrey
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk


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

Re: [OSM-talk] Tagging Governance

[Simon Poole]

Thanks.

BTW I'm not saying that it is always clear when a "good idea" is
actually controversial or that you and Quincy are not subject to
multiple forces pulling or pushing in opposite directions, but the only
solution can be to escalate such issues to a wider audience before
implementation, when that is or becomes clear. Widely harmless current
example: 
https://github.com/openstreetmap/iD/issues/6836#issuecomment-529988108

Am 10.09.2019 um 17:12 schrieb Bryan Housel:
>>>
>>> The decisions we make in iD with the tags are mostly because 1.
>>> someone asked us to in a ticket or pull request, and we try to give
>>> people what they want..  or 2. we are trying to solve an actual
>>> problem - for example, the explicit tagging of piers and platforms
>>> came from us trying to detect routing islands (we rolled this back
>>> when people complained).  
>> Well that is a -slight- simplification of what happened. We can
>> partially follow it here
>> https://github.com/openstreetmap/iD/issues/6409#issuecomment-494888256
>> Except that we don't even know why in the end the changes were reverted,
>> insight? External pressure? Or what? Obviously it wasn't just people
>> complaining or else it would have been far earlier.
>
> I said why here:
> https://github.com/openstreetmap/openstreetmap-website/pull/2267
>
>



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

Re: [OSM-talk] Tagging Governance

[Simon Poole]

Am 10.09.2019 um 16:08 schrieb Bryan Housel:
> Simon you’re completely wrong about this, but I doubt there is anything that 
> I can say that would change your mind.  The "US-corporate bubble" does not 
> care about the tags used by the iD presets as much as you think they do.  

I don't think I remotely implied that the actual tags were at question
in this case.

>
> The decisions we make in iD with the tags are mostly because 1. someone asked 
> us to in a ticket or pull request, and we try to give people what they want.. 
>  or 2. we are trying to solve an actual problem - for example, the explicit 
> tagging of piers and platforms came from us trying to detect routing islands 
> (we rolled this back when people complained).  
Well that is a -slight- simplification of what happened. We can
partially follow it here
https://github.com/openstreetmap/iD/issues/6409#issuecomment-494888256
Except that we don't even know why in the end the changes were reverted,
insight? External pressure? Or what? Obviously it wasn't just people
complaining or else it would have been far earlier.
>
> Anyway, good luck with tagging.  When you frame the discussion this way, 
> don’t be surprised when we are reluctant to participate.

If there was more upfront transparency and discussion then likely the
whole thing likely wouldn't be needed. I'm not saying there wouldn't be
any disagreement, but it would be centred around the actual changes and
not around your behaviour which is what in the end is causing the high
tension.

Simon

>
> Bryan
>
>
>
>> On Sep 10, 2019, at 9:55 AM, Simon Poole  wrote:
>>
>> Roland
>>
>> I can't help noticing that you are tiptoeing a bit around the actual
>> issue which started the whole discussion: unilateral changes by the iD
>> maintainers (everybody else doesn't have enough leverage to enforce
>> their position, so it is not me specifically picking on them, it is
>> simply a consequence of the power they can wield). And these changes are
>> not just questions of which tags to use, but far more fundamental
>> questions, for example implicit vs. explicit tagging (which seems to be
>> something the US-corporate bubble whispered to them, likely that unknown
>> organisations holding the purse strings).
>>
>> If you don't address that I'm not quite sure what the point of the whole
>> discussion is.
>>
>> Simon
>>
>> Am 10.09.2019 um 06:50 schrieb Roland Olbricht:
>>> Hi all,
>>>
>>> I have got into the duty to talk about tagging governance on the SotM
>>> and I would like to develop that opportunity towards something that is
>>> rather helpful in the long term.
>>> To ensure that I am on the right track and not unintentionally after a
>>> personal agenda I would like to ask you to comment on the findings so
>>> far listed below.
>>>
>>> To encourage a widespread discussion, I have spread this message on
>>> German and French lists as well (these two because I understand the
>>> languages) and will do so in addition on the tagging list. Feel free to
>>> spread this message further as long as you remember to channel back all
>>> feedback.
>>>
>>>
>>> Imperfect Flow of Information
>>>
>>> Although many parts of the OpenStreetMap project are well translated,
>>> the tagging documentation has substantial deficiencies. Over a random
>>> sample of 10 tags the number of declared languages varies between 2 and
>>> 18, but only few are complete and up to date (sample: 2 of 10 for
>>> German, 3 of 10 for French).
>>>
>>> Another kind of imperfect information flow is that tag definitions can
>>> be changed on the wiki page long after the tag is in widespread use.
>>>
>>> The converse case that a tag is introduced without any documentation is
>>> also happening. While this happens by ordinary users usually slow enough
>>> to make sense of the added data, an import or organized edit might be
>>> able to substantially skew the de facto meaning of a tag, regardless
>>> whether it is in widespread use, documented, both, or none.
>>>
>>>
>>> More Structure needed
>>>
>>> The translation issues have been conflated with a different problem:
>>> Different features may look very different between regions. E.g.
>>> highway=primary and highway=unclassfied versus highway=track
>>> need different sets of examples in Germany and the urban US on the one
>>> hand and Iceland or rural Africa on the other. It is easy to mix this
>>&g

Re: [OSM-talk] Tagging Governance

[Simon Poole]

Roland

I can't help noticing that you are tiptoeing a bit around the actual
issue which started the whole discussion: unilateral changes by the iD
maintainers (everybody else doesn't have enough leverage to enforce
their position, so it is not me specifically picking on them, it is
simply a consequence of the power they can wield). And these changes are
not just questions of which tags to use, but far more fundamental
questions, for example implicit vs. explicit tagging (which seems to be
something the US-corporate bubble whispered to them, likely that unknown
organisations holding the purse strings).

If you don't address that I'm not quite sure what the point of the whole
discussion is.

Simon

Am 10.09.2019 um 06:50 schrieb Roland Olbricht:
> Hi all,
>
> I have got into the duty to talk about tagging governance on the SotM
> and I would like to develop that opportunity towards something that is
> rather helpful in the long term.
> To ensure that I am on the right track and not unintentionally after a
> personal agenda I would like to ask you to comment on the findings so
> far listed below.
>
> To encourage a widespread discussion, I have spread this message on
> German and French lists as well (these two because I understand the
> languages) and will do so in addition on the tagging list. Feel free to
> spread this message further as long as you remember to channel back all
> feedback.
>
>
> Imperfect Flow of Information
>
> Although many parts of the OpenStreetMap project are well translated,
> the tagging documentation has substantial deficiencies. Over a random
> sample of 10 tags the number of declared languages varies between 2 and
> 18, but only few are complete and up to date (sample: 2 of 10 for
> German, 3 of 10 for French).
>
> Another kind of imperfect information flow is that tag definitions can
> be changed on the wiki page long after the tag is in widespread use.
>
> The converse case that a tag is introduced without any documentation is
> also happening. While this happens by ordinary users usually slow enough
> to make sense of the added data, an import or organized edit might be
> able to substantially skew the de facto meaning of a tag, regardless
> whether it is in widespread use, documented, both, or none.
>
>
> More Structure needed
>
> The translation issues have been conflated with a different problem:
> Different features may look very different between regions. E.g.
> highway=primary and highway=unclassfied versus highway=track
> need different sets of examples in Germany and the urban US on the one
> hand and Iceland or rural Africa on the other. It is easy to mix this
> with the translation into the predominant language in the area,
> but the tagging challenges in Belgium, Canada, and Niger are
> substantially different, although all three countries happen to have
> French as official language. Conversely, there is no sane reason to
> change tagging rules every block of houses in Brussels.
>
> Additionally, people often have different search terms than the British
> English tag names or their translations, and the wiki search engine is
> infamous for its bad performance. Having explicit keywords to direct the
> attention of a mapper to the list of possibly fitting tags might help.
>
> A substantial problem source of the concept of proposals is
> that it interacts with lots of tags in a nontrivial way and is
> practically never properly applied to all affected tag definitions.
> A proposal currently is an extra page although it should have much more
> an impact like a Git commit, grouping changes across various tag
> definition pages in a single changeset.
>
>
> Legitimacy and Governance
>
> What legitimation has a process if only a handful of people have that
> have the time to write mails on a mailing list and to write wiki pages
> are involved? In particular, if the proposals end up as being full of
> contradictions or vague terms and leave necessary answers undefined.
> Yet these still are the people that have shown the necessary long-term
> endurance to assure maintenance and that do the work. Thus every change
> to replace processes with better processes must be geared towards
> broadening not narrowing the base of long-term maintainers.
>
> Conversely, I fully understand mappers that are wary of sudden changes
> in the rendering or the access to tags in edting software. A lot of
> people whould probably appreciate to better understand what happens on
> the way from a tag discussion to a final change in the renderer or
> editing software. These processes are not secret, but often
> under-documented.
>
> Again, the various discussion channels and the lacking information flow
> between them contribute to the b

Re: [OSM-talk] [Osmf-talk] Attribution guideline status update

[Simon Poole]

Am 09.09.2019 um 14:16 schrieb Christoph Hormann:
> On Monday 09 September 2019, Simon Poole wrote:
>>> And what happens if one of the data sources has a hard visible
>>> attribution requirement without the OSMF 'attribution light'
>>> liberty? As you drafted things it would be perfectly all right to
>>> bury OSM attribution on the bottom of some general credits page
>>> while prominently attributing some other source because this was
>>> required while the OSMF settled for less.
>> Where does the draft say that?
> The shoe is on the other foot - where does the guideline draft say that 
> the permission to show OSM attribution only on a separate page under 
> certain conditions depends on no other data source being attributed 
> more prominently?

Why should it? There is no such requirement in the ODbL. I suspect you
are confusing CC BY-SA attribution requirements with those of the ODbL.


> None of your two formulation drafts shown here states anything in that 
> direction:
>
> /If OpenStreetMap data accounts for a minority (less than 50%) part of
> the visible map rendering, attribution with other sources on a separate
> page that is visible after user interaction is acceptable. /
>
> /If OpenStreetMap is not the largest data provider for the visible map
> rendering, attribution with other sources on a separate page that is
> visible after user interaction is acceptable./
>



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

Re: [OSM-talk] [Osmf-talk] Attribution guideline status update

[Simon Poole]

Look I'm sorry that the ODbL is not contact poison.

It is a, in some ways very permissive (so permissive that it isn't even
compatible with the CC BY licenses), open licence with some share-alike
aspects.

The ODbL allows creating extracts of all kinds, vertical, horizontal,
our guidelines ensure,

- that data extracted remains ODbL licenced,

- that third party data that is used in conjunction with OSM data in a
Collective Database remains cleanly separable,

- that OSM data is useful for the sector in general in that it is usable
in similar ways to other datasets if the other prerequisites are fulfilled,

- that the OSM specifics of the database (for example that we are
continuously producing new versions) can't be gamed to make the data
unusable,

- that the best way to fulfil SA obligations is to improve the original
dataset (strictly spoken this is actually a bit at odds with the ODbL),

and last, but not least, that the attribution guideline when it is
finalised is clearer than the current guidance  and helps us massively
reduce unattributed use of OSM data.

Simon

Am 09.09.2019 um 14:14 schrieb Christoph Hormann:
> On Monday 09 September 2019, Simon Poole wrote:
>> Am 09.09.2019 um 12:08 schrieb Christoph Hormann:
>>> Existing guidelines allow a lot of things that are clearly not
>>> allowed by the ODbL itself in terms of share-alike (like the
>>> regional cuts concept for example).
>> That statement is completely wrong. [...]
> I disagree.  And in any case - it does not matter, the regional cuts 
> were used just as an example.  I could likewise have used the 
> horizontal layers as an example in my argument.  And surely you could 
> for those equally present an interpretation of the ODbL that justifies 
> those.
>
> My point is not that you cannot interpret the ODbL in a way that allows 
> all this.  This is what corporate lawyers do and what they are good at. 
> My point is that within the spectrum of possible interpretations of the 
> ODbL all of this is on the far side of leniency and the OSMF - w.r.t. 
> share-alike - has already moved their frame of refrence of what is the 
> appropriate/neutral interpretation very far in that direction.
>
> And i strongly advise you not to do the same for attribution because you 
> are playing with fire here regarding the social cohesion of the 
> project.
>
>>> [...] If you disagree please list cases where commercial OSM data
>>> users have published derivative databases.
>> There is no requirement to publish derivative databases, only a
>> requirement to make them available to recipients of such databases
>> and Produced Works created from them.
> So your argument is that using derivative databases is common practice 
> and map producers routinely make them available to the users of their 
> maps.  But none of this is visible in public because the recipients do 
> not distribute them despite them being available under the ODbL as the 
> license requires?
>
> I am not convinced.
>
> For clarity i repeat and clarify my statement:  Share-alike is 
> functionally dead in the world of commercial OSM map rendering.  Map 
> producers universally route around it - or at least claim to route 
> around it and their claims are not challenged.  If you disagree then 
> show me the derivative databases.
>
>> It doesn't change the license at all, in general the guidance is more
>> -strict- than current practice, with the exception of the multiple
>> source case where there currently isn't any guidance at all.
> So you are essentially saying that commercial OSM data users with their 
> blatant ignorance of the requirements of the license have successfully 
> moved what is considered normal in the eyes of the OSMF so they have 
> adjusted their own frame of reference for what they may expect from 
> data users.
>



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

Re: [OSM-talk] [Osmf-talk] Attribution guideline status update

[Simon Poole]

Just as a general comment and data point on the "the OSMF is scumbling
to commercial interests and throwing the licence out of the window"
narrative.

Ever noticed that while there are lots and lots of sites of all kinds
that use OSM derived base maps and the road network for routing, there
is essentially no use of OSM POI data outside of sites/apps that are
100% OSM based?

Now I realize that our US colleagues won't be able to relate to this,
but there are many regions and areas of the world where OSM POI data is
at a similar level as google, and in breadth clearly better than any
single other commercial POI data provider.

So why doesn't OSM POI data get used at all? Given that there obviously
would be money to be saved here?

Because the name of the game in this specific niche of the business is
merging and de-duplicating datasets of different provenance to get as
complete as possible data, and that is  simply not possible at the kind
of granularity that would be required with OSM data due to the licence. 
From discussions that I've had with typical aggregators of such data it
is clear to them that they can't and won't touch OSM data with even a
very long pole. Has anybody suggested that we give up our
no-deduplication rules, even though it would obviously be very
convenient and lead to more widespread use of OSM data? No.

Simon




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

Re: [OSM-talk] [Osmf-talk] Attribution guideline status update

[Simon Poole]

Am 09.09.2019 um 12:08 schrieb Christoph Hormann:

>
> Existing guidelines allow a lot of things that are clearly not allowed 
> by the ODbL itself in terms of share-alike (like the regional cuts 
> concept for example). 

That statement is completely wrong. What is correct is that the
limitation of such extracts to country size is rather arbitrary, but
that was erring on the side of caution because at increasing smaller
sizes you start getting in to issues with if the resulting extract is
still a database in its own right. But there is nothing at all in the
ODbL that wouldn't in principle allow smaller extracts to be used in
collective databases.

>  They are clearly designed to err on the side of 
> leniency for the data users.  This has been largely accepted by the 
> community because it waives rights the OSMF would have under the ODbL 
> in cases where insisting on them would have relatively little benefit 
> for the project itself (although you could of course still argue that 
> there would be benefit for the open geodata community in general).  But 
> as a result today share-alike in the ODbL is essentially functionally 
> dead.  There are still cases where share-alike is clearly required but 
> almost everyone routes around them.  If you disagree please list cases 
> where commercial OSM data users have published derivative databases.

There is no requirement to publish derivative databases, only a
requirement to make them available to recipients of such databases and
Produced Works created from them.

> Commercial data users (and i am unfairly generalizing here of course) 
> have been answering this extreme generosity in a "Gib jemandem den 
> kleinen Finger und er nimmt die ganze Hand" kind of way when it comes 
> to attribution in particular.  That is to be expected from 
> organizations whose main objective is to maximize short term profits at 
> all costs.  You can be certain that the same approach will be taken 
> with an attribution guideline.  Any loophole in the suggestions 
> presented will be examined for the potential advantages it gives in the 
> most excessive possible interpretation of the text.  
>
> This is why i am strongly opposing the current draft because it pokes 
> additional holes into the license while what it should do is putting a 
> sign on aspects that might be perceived to be loopholes in the license 
> itself with a clear message of: Here the safe terrain ends, we strongly 
> suggest you don't go there if you don't want to get in legal trouble or 
> potentially face the wrath of hundreds of thousands of OSM contributors 
> and supporters.

It doesn't change the license at all, in general the guidance is more
-strict- than current practice, with the exception of the multiple
source case where there currently isn't any guidance at all.

Simon




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

Re: [OSM-talk] [Osmf-talk] Attribution guideline status update

[Simon Poole]

Am 09.09.2019 um 02:03 schrieb Joseph Eisenberg:
> In the case of 10 sources with ODbL attribution requirements, I would
> still prefer that (c)Openstreetmap be included on the rendering,
> because this is the only ODbL project that is totally free and open
> and created by individual volunteers, as far as I am aware.
>
> Government-created databases have already been paid for by taxpayers,
> and will not stop existing if no one knows about them. But
> Openstreetmap needs new contributors, so we need people to know that
> we exist.

I fully agree with the above, but it is not a legal argument that can be
used in interpreting the consequences and requirements of our
distribution licence.

And may I add, requiring grossly inaccurate attribution doesn't actually
help with any of our issues.

>
> However, as I mentioned above, I'm fine with providing a link to ALL
> copyright and attribution notices, when it's physically impossible to
> attribute them all properly due to limited space.
The draft guideline doesn't say anything else. It simply tries to
address the edge case where there is limited space and OSM is not the
dominant data source and attributing everything to OSM would be
confusing and inappropriate.
>
> This means that there can't be a "facebook" or "Mapbox" logo on the
> map: just a link "copyright attribution" or "data sources" (or "i" if
> it's a tiny 100x100 pixel map) - ideally this would pop up without
> needing to click, if it's online.
>
> If the map renderer wants to include their logo, then they must
> include (c)Openstreetmap as well (or perhaps (c)OSM if it's a tiny
> 200*200 pixel / 2cm*2cm map and their own logo is tiny)
>
> If the map renderer wants to include a link to their website or any
> other website on the online or rendered map, then they have to include
> a link to Openstreetmap.org. Full stop.
>
> Please provide a practical real-world example where these requirements
> are impossible to meet, if I'm mistaken.

Kathleen has already touched on this, but one more time. In general the
guidelines work as safe harbours, that is if somebody follows the
guidelines in good faith they can assume that they are doing something
we're reasonably happy with. That does not mean that the guidelines
change the licence and that attribution solutions that do not conform to
our guidelines would automatically be licence violations. In a legal
conflict, while our guidelines would surely be considered, if they are
loaded with restrictions that are not actually present and founded in
the licence they would likely not hold much weight.

For example Facebooks f logo is small and very well recognized, making
how -OSM- should be attributed dependent on if the f logo is present or
not, would be, IMHO, very contrived as it has no bearing on if
attribution as required by the licence can be provided or not. I should
note that this is a hypothetical, Facebook doesn't display a logo on the
small inset maps nor on the larger popup maps on their website.

Simon

>
> - Joseph Eisenberg
>
> On 9/9/19, Simon Poole  wrote:
>> To illustrate where this discussion has gone awry please consider a
>> rendering using 10 data sources all licensed on ODbL terms (in real life
>> it is not uncommon to have multiple dozens of different sources, so 10
>> is not a high number).  The ODbL does not, nor does any other open
>> licence, intend for such a product not to be possible because of the
>> practicalities of  providing simultaneously visible attribution of all
>> sources all the time.



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

Re: [OSM-talk] [Osmf-talk] Attribution guideline status update

[Simon Poole]

Am 09.09.2019 um 01:41 schrieb Joseph Eisenberg:
> Re: > where to put the attribution when multiple sources have been
> used in a map rendering and OSM is not the source of the majority of
> the data presented.
>
> On (or on top of) the rendered map, in the same font weight as any
> other logo or other copyright notice, and preferably with a clickable
> hyperlink to https://www.openstreetmap.org (only required if this is
> also offered for other features on the map).
>
> The (c)Openstreetmap should be included if any other attribution is
> included. If there isn't room for (c)OSM, then there should not be any
> other logo or copyright on the map either. In in this case a generic
> "i" or "(c)" link could be included to another page - so the only
> situation where Openstreetamp attribution should not be shown on the
> map is where there is not room for any attribution or logo.

(c)OSM is not sufficient nor something that we could require as
attribution for a host of different reasons. So could we please stay on
topic.

>> Nobody is making any exceptions.
> The currently policy seems to allow rendered maps to show the logo of
> the map renderer and copyrights of other data sources on the map if
> they make up the majority of the data shown, without showing the
> Openstreetmap copyright notice or link. I think it's clear that
> several contributors disagree with this exception, myself included.

There is no current guidance for the use of multiple sources which is
why we are in the progress of  developing one.

The reason why it is completely sensible to not require on map
attribution when OSM data is not the major part of the data presented,
is because OSM is not the major part of the data presented. We should
not be interested in having wonky data from, choose your favourite OSM
competitor, being attributed to us (btw we get enough mistaken
complaints as is) and there is a trade off between accuracy and the room
required to express that and the simplicity and visibility of the
attribution.

As laid out in the intro to the document, the attribution that is
provided should not be confusing and should enable the person
interacting with the produced work to determine what data is obtained
from "the database", aka OSM in our case. Blanket attribution to OSM of
all sources used does not do that.

Simon

> -Joseph Eisenberg
>
> (Disclosure: Just a volunteer contributor as a mapper and at
> Openstreetmap-carto, I don't have any financial interest in this
> project, nor will the copyright policy directly affect me, except when
> I print out maps, I suppose)
>
> On 9/9/19, Simon Poole  wrote:
>> Am 08.09.2019 um 23:52 schrieb Christoph Hormann:
>>> On Sunday 08 September 2019, Clifford Snow wrote:
>>>> Christoph,
>>>> What would you recommend and how can it be implemented and tested to
>>>> insure compliance with the license? How does the user of OSM data
>>>> figure out what data is counted in the threshold for requiring full
>>>> attribution. Especially when the OSM usage may just be a basemap from
>>>> a 3rd party tile server.
>>> I think any substantial use of OSM data should be attributed in a way
>>> that is "reasonably calculated to make any Person that uses,
>>> views, accesses, interacts with, or is otherwise exposed to the Produced
>>> Work aware that Content was obtained from" - like the license says.  No
>>> exceptions.
>> Nobody is making any exceptions.
>>
>> Simon
>>
>>
>>



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

Re: [OSM-talk] [Osmf-talk] Attribution guideline status update

[Simon Poole]

To illustrate where this discussion has gone awry please consider a
rendering using 10 data sources all licensed on ODbL terms (in real life
it is not uncommon to have multiple dozens of different sources, so 10
is not a high number).  The ODbL does not, nor does any other open
licence, intend for such a product not to be possible because of the
practicalities of  providing simultaneously visible attribution of all
sources all the time.

Am 09.09.2019 um 00:10 schrieb Joseph Eisenberg:
> The attribution should be at least (c)OpenStreetMap, but it's fine to
> give more detail like:
>
> 1. Using just the coastal shoreline in the basemap:
>
> (c) OtherDataSource, coastline (c)OpenStreetMap
>
> 2. Using OSM basemap in 1 along with roads, rivers and water bodies
>
>  (c) OtherDataSource, basemap (c)OpenStreetMap
>
> 3. Using OSM basemap with 2 and buildings
>
> (c)OpenStreetMap,  (c) OtherDataSource
>
> It seems simpler to just clearly state "you need to include
> (c)OpenStreetMap on the map if you use OpenStreetMap" rather than
> making more complicated rules.
>
> - Joseph Eisenberg
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk



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

Re: [OSM-talk] [Osmf-talk] Attribution guideline status update

[Simon Poole]

Nobody is even remotely suggesting that use OpenStreetMap data can be
used without attribution (claims that that is the case lead me to
believe that some haven't actually read the document in question).

The discussion is solely about the practicalities  of where to put the
attribution when multiple sources have been used in a map rendering and
OSM is not the source of the majority of the data presented.

Simon

Am 08.09.2019 um 23:48 schrieb stevea:
> I don't want to sound overly simplistic, but as a copyright holder, I believe 
> if ANY amount of my (or "our" in the sense of copyright shared among many 
> individuals, as are the rights in OSM's ODbL) data-under-license are included 
> in a derivative work, and I mean ANY non-zero amount, "attribution" (as ODbL 
> defines attribution) is legally required.
>
> I believe ODbL agrees with this (there is no mention of "percentages" there), 
> though I am not an attorney.  Why is this so difficult?
>
> "Any non-zero amount of OSM data yields a legal requirement for proper 
> attribution."  Do I miss something?
>
> SteveA
> 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk



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

Re: [OSM-talk] [Osmf-talk] Attribution guideline status update

[Simon Poole]

Am 08.09.2019 um 23:52 schrieb Christoph Hormann:
> On Sunday 08 September 2019, Clifford Snow wrote:
>> Christoph,
>> What would you recommend and how can it be implemented and tested to
>> insure compliance with the license? How does the user of OSM data
>> figure out what data is counted in the threshold for requiring full
>> attribution. Especially when the OSM usage may just be a basemap from
>> a 3rd party tile server.
> I think any substantial use of OSM data should be attributed in a way 
> that is "reasonably calculated to make any Person that uses,
> views, accesses, interacts with, or is otherwise exposed to the Produced
> Work aware that Content was obtained from" - like the license says.  No 
> exceptions.

Nobody is making any exceptions.

Simon




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

Re: [OSM-talk] [Osmf-talk] Attribution guideline status update

[Simon Poole]

Am 08.09.2019 um 20:37 schrieb Christoph Hormann:
> On Sunday 08 September 2019, Simon Poole wrote:
>> I think you are confusing potentially extractable information with
>> actual data. For example satellite imagery may have a potentially
>> high information content that could be with appropriate processing be
>> turned in to data, but each image in itself is at most one datum.
> I see - so you want to quantify by counting 'data objects' of some sort.  
> I assume for the OSM side you want to go with the quantification of one 
> OSM feature equals one countable object and a large lake multipolygon 
> for example can count a few thousand?
>
> You'd still loose by a huge margin in a map with contour line relief 
> rendering of course.
>
> And i would still hold the bet that i would be able to get the OSM 
> fraction of any map below 50 percent without too much effort.
>
>> Now waiting for the every image is a pixel database argument.
> You are aware that most satellite image layers used in visualizations 
> are produced from hundreds of thousands or even millions of individual 
> images, assembled pretty much in the same way as a map rendering is 
> assembled from multiple features.  It therefore seems your 'one datum' 
> concept is somewhat fragile.

I wrote "at most" one datum, I would argue that that an image is an
image (even if it is a composite image) and not a datum.

But in any case the guideline refers to the  "visible map rendering". At
least in conventional use of the term, aerial imagery is not a map, but
if you so which we could surely add a definition for "map" that makes it
clear that we are referring to the rendering of map vector data and
similar and not image-like layers.

Simon

>
> I see exactly one possible quantification of data fractions in a map 
> that could not be easily circumvented.  That would be based on the 
> number of human work hours that went into producing the data.  This is 
> a rule i could support:  If more human work hours went into producing 
> the non-OSM source data used in a map than in the OSM data used 
> attribution that is hidden by default is acceptable.
>



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

Re: [OSM-talk] [Osmf-talk] Attribution guideline status update

[Simon Poole]

Am 08.09.2019 um 19:39 schrieb Christoph Hormann:
> On Sunday 08 September 2019, Simon Poole wrote:
>> /If OpenStreetMap is not the largest data provider for the visible
>> map rendering, attribution with other sources on a separate page that
>> is visible after user interaction is acceptable./
>>
>> [...]
> For understanding the practical function of such a rule (and the efforts 
> necessary to circumvent it of course) - how do you measure the fraction 
> OSM accounts for as data provider for a map, especially if several 
> different data types are involved.  If you go by data volume (which can 
> be easily changed by several orders of magnitude through geometry 
> compression and expansion methods of course) i would probably say i 
> have never seen a map with relief depiction (like shading or countour 
> lines) where the majority of the data is from OSM.  Any satellite image 
> layer with annotation labels and lines (boundaries, roads etc.) from 
> OSM would equally be exempt from visible attribution under such rule.

I think you are confusing potentially extractable information with
actual data. For example satellite imagery may have a potentially high
information content that could be with appropriate processing be turned
in to data, but each image in itself is at most one datum. Now waiting
for the every image is a pixel database argument.

Simon 

>
> Practically i think everyone should be aware that such rule is a clear 
> invitation how to avoid the need for attribution for map producers.  I 
> would go as far as saying that no matter how you answer my question as 
> to how data fractions are measured any map could be easily modified by 
> adding sufficient other data to get the OSM fraction below the 50 
> percent limit and this way get off the hook.
>
> As already said i don't see how such a recommendation could in any way 
> be considered compatible with the ODbL attribution requirements.
>



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

Re: [OSM-talk] [Osmf-talk] Attribution guideline status update

[Simon Poole]

BTW a potential tweak to the wording (caveat: not discussed with
anybody) that would perhaps make the multiple data sources scenario work
a bit better is to change the current

/If OpenStreetMap data accounts for a minority (less than 50%) part of
the visible map rendering, attribution with other sources on a separate
page that is visible after user interaction is acceptable. /

//

to

//

/If OpenStreetMap is not the largest data provider for the visible map
rendering, attribution with other sources on a separate page that is
visible after user interaction is acceptable./

Which would require on map attribution not only for the 50% and more
case, but also for any case in which the majority of the visible data is
from OSM. It does break down a bit when there are numerous small data
sources of very similar size. Naturally one can argue about what
"largest" means in the context which however applies to the suggested
50% rule too.

Simon

Am 08.09.2019 um 16:38 schrieb Simon Poole:
>
> I don't quite follow your argument here. According to the draft
> guideline if a majority of the data displayed is derived from OSM,
> then attribution needs to be displayed on map. So assuming that the
> prerequisite is met, as you are saying, the draft guideline would
> require exactly what you want.
>
> The -other- problem with the site is that it is implying a partnership
> which doesn't exist. Something which we clearly don't want for
> commercial law and liability reasons, given the wording of the ODbL I
> doubt that we can base such a requirement on the licence (but likely
> on use of our trademarks).
>
> Simon
>
> Am 08.09.2019 um 12:11 schrieb Nuno Caldeira:
>>
>> Here's another example of why we should not adopt the multiple
>> sources attribution omission of our attribution. They list us as
>> partners (?)
>> https://www.wrld3d.com/3d-maps/custom-maps
>> Use multiple sources and are not complying with ODbL by not showing
>> the license.
>> Seen multiple maps by their clients and they show data "copyright l.map"
>>
>> I have confirmed with multiple contributors that largely the data
>> used is OSM and it's around a year old dump of the planet.
>>
>> Simon Poole mailto:si...@poole.ch>> escreveu em sex,
>> 9/08/2019 às 08:45 :
>>
>> As we've mentioned multiple times over the last months, the LWG
>> decided
>> last year to consolidate all attribution guidance in to one
>> document and
>> address some of the use cases that have become common over the last 7
>> years that previously had none. Particularly in the light of the
>> parallel discussions about attribution on larger social media
>> platforms
>> we need to make up our minds what we actually want, and define
>> concrete
>> minimum requirements for acceptable attribution. To not do this just
>> provides the excuse of pointing to the cacophony of voices all saying
>> something different. 
>>
>> We've been working on and off on the document for a while, and
>> are now
>> largely finished. Going forward we intend to wikify the document and
>> make it available for public comment together with a BoF session
>> at SotM
>> next month (which probably means that we'll have to appropriate a
>> coffee
>> break). You can have a glimpse at the text here
>> 
>> https://docs.google.com/document/d/1e_IQYHtqVivGRw4O4EOn6__-LGMuzPlWz6XKEdAkwW0/edit?usp=sharing
>> the few things that are not nailed down belong to those that we would
>> appreciate feedback on.
>>
>> Simon
>>
>> PS: the number of coffee breaks permitting we might want to
>> appropriate
>> another one for the discussion of a tile licence change.
>>
>>
>> ___
>> osmf-talk mailing list
>> osmf-t...@openstreetmap.org <mailto:osmf-t...@openstreetmap.org>
>> https://lists.openstreetmap.org/listinfo/osmf-talk
>>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk


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

Re: [OSM-talk] [Osmf-talk] Attribution guideline status update

[Simon Poole]

I don't quite follow your argument here. According to the draft
guideline if a majority of the data displayed is derived from OSM, then
attribution needs to be displayed on map. So assuming that the
prerequisite is met, as you are saying, the draft guideline would
require exactly what you want.

The -other- problem with the site is that it is implying a partnership
which doesn't exist. Something which we clearly don't want for
commercial law and liability reasons, given the wording of the ODbL I
doubt that we can base such a requirement on the licence (but likely on
use of our trademarks).

Simon

Am 08.09.2019 um 12:11 schrieb Nuno Caldeira:
>
> Here's another example of why we should not adopt the multiple sources
> attribution omission of our attribution. They list us as partners (?)
> https://www.wrld3d.com/3d-maps/custom-maps
> Use multiple sources and are not complying with ODbL by not showing
> the license.
> Seen multiple maps by their clients and they show data "copyright l.map"
>
> I have confirmed with multiple contributors that largely the data used
> is OSM and it's around a year old dump of the planet.
>
> Simon Poole mailto:si...@poole.ch>> escreveu em sex,
> 9/08/2019 às 08:45 :
>
> As we've mentioned multiple times over the last months, the LWG
> decided
> last year to consolidate all attribution guidance in to one
> document and
> address some of the use cases that have become common over the last 7
> years that previously had none. Particularly in the light of the
> parallel discussions about attribution on larger social media
> platforms
> we need to make up our minds what we actually want, and define
> concrete
> minimum requirements for acceptable attribution. To not do this just
> provides the excuse of pointing to the cacophony of voices all saying
> something different. 
>
> We've been working on and off on the document for a while, and are now
> largely finished. Going forward we intend to wikify the document and
> make it available for public comment together with a BoF session
> at SotM
> next month (which probably means that we'll have to appropriate a
> coffee
> break). You can have a glimpse at the text here
> 
> https://docs.google.com/document/d/1e_IQYHtqVivGRw4O4EOn6__-LGMuzPlWz6XKEdAkwW0/edit?usp=sharing
> the few things that are not nailed down belong to those that we would
> appreciate feedback on.
>
> Simon
>
> PS: the number of coffee breaks permitting we might want to
> appropriate
> another one for the discussion of a tile licence change.
>
>
> ___
> osmf-talk mailing list
> osmf-t...@openstreetmap.org <mailto:osmf-t...@openstreetmap.org>
> https://lists.openstreetmap.org/listinfo/osmf-talk
>


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