Re: [talk-au] How to efficiently improve AU address coverage?

[Simon Poole]

Except if something has massively changed, the GNAF data isn"t actually open.

Am 2. Oktober 2023 13:05:10 MESZ schrieb Daniel O'Connor 
:
>While OSM doesn't have layers, https://openaddresses.io/ more or less acts
>as the address layer. The datasets there aren't all ODBL, but they are
>generally open. It includes GNAF. Given how frequently addresses update, to
>keep it in sync with OSM would be pretty significant and hard to reconcile
>with surveyed, on the ground data.
>
>Getting addresses into OSM is useful for routing, etc, but there might be
>more niche datasets that can be of value.
>
>Maproulette is potentially a good way to generate *probably correct but
>needs verification *data.
>Are there questions you can frame that people can answer with remote
>mapping?
>
>IE:
>Company X has said they will put solar on all of their stores by (date),
>but there are no solar panels within 50m of (store.location)
>Company Y shut down, is this store still open?
>School area Z doesn't have any sports fields/buildings/etc - are there any
>to be mapped?

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

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 
 with examples of usage 
. 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 



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: [talk-au] 'Named' EV chargers

[Simon Poole]

See https://www.openstreetmap.org/user/SimonPoole/diary/397565 while 
amenity=charging_station is not the worst offender, it is still pretty 
bad 
https://github.com/osmlab/name-suggestion-index/blob/main/data/brands/amenity/charging_station.json


Am 15.12.2022 um 04:20 schrieb Phil Wyatt:


Hi Folks,

Thoughts on 'named' EV chargers? Around 50% of chargers in Oz have 
some 'name'.


Most look to be adding the either the location or name of the operator 
etc (ie Freds Shop, XYZ carpark, Tesla supercharger etc), I suspect so 
it gets rendered on the map.


Are folks happy if I remove the names. I will ensure that no details 
are lost by making sure any operator or network details gets added to 
the correct tags.


(I will also post to Oceania Forum and Discord)

[Overpass query](https://overpass-turbo.eu/s/1p4u)

Cheers - Phil


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


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

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 
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: [talk-au] New OSM Discourse site: community.osm.org

[Simon Poole]

I wouldn't expect much traffic till the existing forum content has been 
migrated, currently scheduled for the end of the month. That should then 
give some slightly more definite structure to things than there is now.


Simon

Am 02.05.2022 um 05:01 schrieb Sam Wilson:


It's growing in use, I think (not with Australia-specific discussion).

It feels like a pretty good site, I check the headlines most days, and 
I think one advantage is being able to get a feel for what's being 
discussed elsewhere. Also to have location-specific discussions that 
benefit either from the input of people elsewhere or to let other 
people know how one place is doing things.


I don't like the notification system that much, but part of that is I 
think that the ratio of meta posts to real topical ones is quite large 
at the moment. It is decreasing though, as more people take part.


—Sam


On 1/5/22 06:28, Graeme Fitzpatrick wrote:

So how's it going after this first month?

Any marked advantages / disadvantages over the existing mailing list?

Thanks

Graeme


On Tue, 22 Mar 2022 at 12:52, Sam Wilson  wrote:

The new community.openstreetmap.org
 site is up and running.

It's going to replace the old forum, including the users:
Australia 
subforum.

I'm not sure if we should ask for an Australia category to be
created on the new site. Probably not worth it until there's some
amount of content relating to Australia.


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



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


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

Re: [talk-au] Attribution 4.0 International (CC BY 4.0)

[Simon Poole]

Just to clarify, the OSMF doesn't just requires the waiver because it is 
being difficult.


CC BY has fundamental issues that are widely ignored, the blog post is 
simply the diplomatic summary that we hammered out together with CC (it 
says so much in the text).


Simon

Am 01.12.2021 um 07:54 schrieb Brendan Barnes:

Hey John,

The Legal Eagles of the OSMF Licence Working Group continue to ask for 
explicit permission (ie waiver) for CC BY 4.0. The rationale is at 
https://blog.openstreetmap.org/2017/03/17/use-of-cc-by-data/


You can reach them via their contact details at 
https://wiki.osmfoundation.org/wiki/Licensing_Working_Group for any 
clarifications, but it appears they have already assessed the wording 
in CC BY 4.0.


I know waivers can be difficult to obtain, and government entities may 
have internal red tape or few resources available to supply one to the 
OSM community. However it's in everyone's best interest, and once we 
have a waiver on file for the agencies' datasets, they are good to use 
indefinitely.


..Brendan


On Wed, 1 Dec 2021 at 15:53, John Luan  wrote:

Hi Guys,

Had a look at this license
https://creativecommons.org/licenses/by/4.0/deed.en

Do we really need a waiver from the data provider? something like
this

https://wiki.openstreetmap.org/w/images/1/17/AADC_CC-BY_Permission_JK_signed.pdf

My feeling is that as long as we list the data provider on the
contributor list, it should be fine.

Regards,
John
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au


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


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

Re: [talk-au] Suburbs: Nodes, Areas, or both?

[Simon Poole]

Am 06.11.2021 um 10:22 schrieb fors...@ozonline.com.au:

Quoting Simon Poole :

PS: wondering why Gruyere has that name.


Good question.
The town is named for a variety of cheese, as the area's history is in 
the dairy industry. Cahillton Post Office first opened on 20 August 
1892. It was renamed Gruyere in 1950 and closed in 1960

Wikipedia

Yes, Gruyère is a cheese, it's named after the town of Gruyères see 
https://en.wikipedia.org/wiki/Gruy%C3%A8res, very nice place BTW. That's 
why I was wondering :-), but I suppose the dairy indsutry explains it.


Simon


Tony




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

Re: [talk-au] Suburbs: Nodes, Areas, or both?

[Simon Poole]

This is a somewhat unsolved issue in OSM modelling, as both area 
(extent) and node (assuming it is not simply the centroid of the area) 
convey geometric information that the other cannot. IMHO best would be 
to have a similar concept as we do for administrative areas that works 
for "places" in a more general sense, that is that allows simple 
deduplication of the elements.


A rather epic discussion on the topic can be found here: 
https://github.com/gravitystorm/openstreetmap-carto/pull/2816


Simon

PS: wondering why Gruyere has that name.

Am 05.11.2021 um 07:53 schrieb cleary:

Ideally suburbs would have a relation for the boundary PLUS a node for the "label 
node" as part of the relation.   I'm not so familiar with Victorian locations, but 
this example for South Albury in NSW is an example:
https://www.openstreetmap.org/relation/5901488

Where there is a boundary and a separate place node, I would add the place node to the 
relation and its role would be "label node".



On Fri, 5 Nov 2021, at 2:15 PM, Dian Ågesson wrote:

Hey all,

I would appreciate the thoughts of the community with regards to suburb
representations.

In a recent change set
(https://www.openstreetmap.org/changeset/113355648) a node was
introduced for Gruyere. Gruyere is on the urban boundary, but is
technically in Metropolitan Melbourne. As such, it straddles the border
between what could be considered a bona fide suburb, and an independent
town.

Mick has correctly pointed out that many of the other localities in the
area are represented by both an area and a node.

Is this the way all suburbs should be represented? Or is it an
urban/rural distinction?



Dian

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

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


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

Re: [talk-au] Friend requests from 'Porn Bots'

[Simon Poole]

Am 12.09.2021 um 13:56 schrieb Andy Townsend:


It'll hopefully be deleted by the time that anyone gets to read this, 
so not much point really.



Getting their link distributed is exactly what the operators want, so 
-never- do that.




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

Re: [talk-au] Import vs filtering query

[Simon Poole]

Hi

Your proposed workflow would seem to be totally OK to me and is clearly 
not an import. List the government data in the sources used in the 
changeset and IMHO you are good to go.


Simon

Am 04.09.2021 um 12:51 schrieb Little Maps:


Hi all, my understanding is that the process described below is a big 
filtering exercise rather than a data import, but since I’ve never 
been involved in an import before, I’d like to check before 
progressing. Thanks in advance for your feedback.



Goal: to update road surface tags across regional Victoria where 
necessary. Many surface tags were added 8-10 years ago and a 
surprising number of roads have been surfaced since then. (I’m only 
interested in sealed/paved vs unsealed/unpaved options, not subsets of 
these.)



Method: compare road surface data in OSM against data in the Vic 
government’s transport dataset which we have permission and waiver to 
use. All rural roads from motorways to unclassified (not residential, 
service, etc) that have different tags in OSM and the gov dataset will 
be examined against satellite imagery and Mapillary, and any decisions 
on whether to update the surface tags will be made based solely on the 
imagery. No data will be directly copied from the gov dataset. Hence, 
as I understand osm’s import guidelines, this is a big filtering 
exercise rather than an import. Is that a correct interpretation? I’ve 
added a longer explanation below to help answer any questions.



Basic assumptions: (1) I assume both datasets were made independently, 
as I’ve not seen any evidence that OSM surface tags were copied from 
the Vic data (or that the gov copied from OSM). (2) If the 2 
independent datasets both indicate the same surface then I assume it 
is most likely to be correct. If they indicate different surfaces then 
one must be in error. At the outset, I have no idea how accurate the 
Vic gov dataset is, so I’m not assuming it is infallible (it’s 
definitely not; see comment below).



Methods: for every road segment that has a different surface tag in 
the 2 datasets, I’d inspect the road using available imagery, as is 
normally done when adding or updating a surface tag. Existing OSM tags 
will either be altered or retained, as required. There’s no ambiguity 
involved in updating a tag from unpaved to paved. It’s much less 
common to need to update a tag from paved to unpaved. Again, this will 
be done based on imagery, regardless of what the Vic data says.



Some prelim observations: I’ve trialled the method in NW Vic, where 
the method works fine on longer road segments/ways. The approach would 
have to be restricted to ways > 1-2 km long, and short ways will be 
ignored. From an initial subset of about 50 roads > 5 km long in NW 
Vic, I found about 2/3 of the discrepancies between the 2 datasets did 
not warrant any change in OSM and about 1/3 did. The Vic gov data 
doesn’t seem to be as up-to-date as the imagery and isn’t by any means 
perfect. Regardless, the approach looks to be a very effective way to 
find out-of-date and inaccurate road surface data across the state.



At this stage I don’t know how many ways will be examined or changed, 
as it will depend on the minimal length of road I inspect. I’m 
envisaging about 1000 at the max, and probably fewer.



My guess is that, if the process was completed across Vic, then the 
surface data in OSM would be extremely accurate, and more accurate 
than in the Vic gov database. If I get through enough of it without 
going bonkers, I’m interesting in summarising the findings to show 
which discrepancies were most common, etc.



So, back to the original question, is this process ok to pursue, given 
that the sole function of the gov dataset is to provide a filtering 
mechanism to identify roads to investigate, and all decisions will be 
made based on legally available imagery, not the gov data?



Thanks very much for your feedback, Ian


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


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

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

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


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 

___
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-legal-talk] Brexit & EU database rights

[Simon Poole]

https://www.gov.uk/guidance/sui-generis-database-rights-after-the-transition-period 
is the UKs governments guidance on this.  On re-reading I agree that the 
withdrawal agreement itself is rather ambiguous, and there is a lot of 
conflicting advice on the matter, see for example 
https://www.google.com/url?sa=t=j==s=web==rja=8=2ahUKEwiL38fux83tAhXNCuwKHYHXAjgQFjABegQIAhAC=https%3A%2F%2Fwww.herbertsmithfreehills.com%2Ffile%2F37041%2Fdownload%3Ftoken%3DOr7GPtMf=AOvVaw0jZK9j_3jP6xJNsnbzaKJ5 
or 
https://www.gevers.eu/en/tb8PacLcwp/brexit--copyright-and-sui-generis-database-right.php 
that states just like the UK governments guidance that the rights will 
continue on post end of the transition period in the EEA.


I suspect clarity on this could only come from the official EU side of 
things, not that it really matters as in any case action is required by 
the OSMF.


Simon

Am 14.12.2020 um 13:34 schrieb Tom Hummel:

Hi Simon,

My understanding is that 58.2 covers the rights of UK based entities, 
with other words it extends the directives article 11 to cover UK 
residents and entities.
From 58 II: “The following persons and undertakings shall be deemed to 
comply” … (basically) people and entities in the UK.


Does “deem to comply” mean, those persons have to comply? It reads as 
if the people mentioned in 58 II are subject to an obligation (the 
duty to obey the rights from 58 I) not the beneficiary. 58 seems to 
talk about EU entities that are, essentially, UK based or active 
within the UK.


Art 58 in general seems to be concerned with continuing EU database 
law within the the UK for EU subjects, not the other way around: 
“holder of a right in relation to a database […] maintain an 
enforceable intellectual property right in the United Kingdom, under 
the law of the United Kingdom”.


Meaning, OSMF, or any EU entity ftm, continues to hold database rights 
within the UK, but not within the EU – only under more general 
provisions. Not even art. 4 TRIPs seems to grant any more rights, 
since lack of any other more favorable agreements among trips members.


I have found an english legal opinion:
===
https://www.womblebonddickinson.com/uk/insights/articles-and-briefings/brexit-and-database-rights


Accordingly, in the event no agreement is reached […] whereby:

· the UK will continue to recognise Database Right of EU (and UK) 
qualifiers so they will not lose rights to which they were entitled 
in the UK on the date of withdrawal


· the EU will cease to recognise Database Right of UK qualifiers in 
respect of databases created *before* the date of withdrawal.

Thanks for your courtesy!

Tom









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

Re: [OSM-legal-talk] Brexit & EU database rights

[Simon Poole]

My understanding is that 58.2 covers the rights of UK based entities, with 
other words it extends the directives article 11 to cover UK residents and 
entities.

Am 14. Dezember 2020 00:11:25 MEZ schrieb Tom Hummel via legal-talk 
:
>Simon,
>
>sorry for reopening.
>
>> This was the subject of the original message in this thread. The 
>> situation post December 31st 2020 is such that protection for sui 
>> generis databases will remain for database published before that date
>in 
>> the UK till the protection term runs out. In the case of OSM when the
>15 
>
>Thanks, I see you are referring to art. 58 of the withdrawal agreement
>https://eur-lex.europa.eu/legal-content/EN/TXT/?qid=1580206007232=CELEX%3A12019W/TXT%2802%29
>
>The UK government explains this as follows: “Database rights that exist
>in the UK or EEA before 1 January 2021 (whether held by UK or EEA
>persons or businesses) *will continue* to exist in the UK *and EEA* for
>the rest of their duration.”
>
>As far as I understand the article, however, there is protection within
>the UK for European entities. Yet, I can’t find a provision which
>covers the issue vice versa, i.e. an UK entity would loose protection
>within EEA.
>
>I think the accepted term for this is ’reciprocity gap’. I am not sure
>if my understanding of english legal communications is good enough for
>this.
>
>The 15y period was not intended to provide protection against change of
>law. I suppose it’s a protection of investment for a certain amount of
>time. Without EU membership the premises for the law changes. According
>to this, OSMF might loose standing in respect to the directive in
>german courts. (EEA too?)
>
>Thanks
>
>Tom
>
>
>
>___
>legal-talk mailing list
>legal-talk@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/legal-talk

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

Re: [OSM-legal-talk] Brexit & EU database rights

[Simon Poole]

Am 13.12.2020 um 22:43 schrieb Edward Bainton:

Ok, so let me rephrase about 'moving the database'.

I mean moving the domicile of OSMF, as legal owner of the database. 
This is being discussed. (See LWG minutes for September)


Does anyone have a clear idea what that would do for the protection of 
the database as it currently stands? Would it be strengthened versus 
the protection that covers the database at the moment (which is 15 
years of UK database right mimicking EU database right, under the 
Brexit 'withdrawal agreement'. It seems the start-date of those 15 
years is unclear).


Or does the current database not get any greater protection once the 
owner is domiciled in the EU?


IMHO the above questions are unanswerable at the moment, the fuzziness 
with respect to when we consider the database last published is however 
really not related to the BREXIT question, but more to the provisions in 
article 10 which I've already pointed to. Would the OSMF successor be 
required to show that it had made changes as in 10 III to the database 
after it had been founded and domiciled in the EU? There is really just 
no way to know and nobody is chomping at the bit to go to court to find out.


What does moving domicile to the EU do for the protection of the edits 
added to the database after domicile has moved into the EU - are these 
protected under the EU database rights or not? I feel this question 
reduces to,

- are the edits a new database to which EU database rights attach?
- or are they insubstantial modifications of a database that came into 
the EU without EU database rights attached, and therefore the new 
edits are not covered by EU database right?


The database as a whole is protected, not the edits (outside of 
potentially collectively being a database themself). Making 
insubstantial changes to the database doesn't change protection of its 
contents or newly added or changed data, making substantial changes will 
create a new database.




Are these questions clear?

(Not that OSMF can strictly *move* domicile: it will have to register 
a subsidiary legal person in an EU country, move its intellectual 
property into the subsidary, then possibly admit all current OSMF 
members as members of the subsidary and close the parent (ie, close 
the current London-registered OSMF. Or an equivalent process.)


If it was easy it would have been done a long time ago. The additional 
complication is that I expect (who knows what the OSMF board is 
thinking) that we would want to create a proper membership based 
organisation which, using a broad brush here, can't be subsidiaries of 
other legal entities.


Simon



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



Am 13.12.2020 um 20:12 schrieb Tom Hummel via legal-talk:
> Hi all,
>
> Am Sonntag, 13. Dezember 2020, 15:58:48 CET schrieb Simon Poole:
>> The relevant bit of the directive is in article 11. As you can
see the
>> rights are dependent on being domiciled in the EU, not on the
physical
>> location of the "database". I would need to check up on the UK
> Do the legal contributors have formed an opinion towards this,
already?
>
> Seeing the Foundation being situated in the UK, and the absence
of any agreement acc. to art. 11 III, it looks like the foundation
is loosing its entitlement acc. to art. 11 II of the directive.

This was the subject of the original message in this thread. The
situation post December 31st 2020 is such that protection for sui
generis databases will remain for database published before that
date in
the UK till the protection term runs out. In the case of OSM when
the 15
years start is naturally a bit fuzzy, but at least the reworking
of the
database in 2012 for the licence change was clearly a substantial
change
that required a significant investment by the OSMF, so it is
reasonable
to assume that protection will remain at least till September 2026
(IMHO
there are more than enough arguments for December 2034, but I suspect
that will be moot by 26).

Simon

>
> German courts adhere to the „modified seat of management rule“
since 2002 (BGH NJW 2002, 3539), meaning some capacity to sue and
be sued. OTOTH liability for associates is personal and unrestricted.
>
> For Germany, it looks like there is some entitlement on behalf
of FOSSGIS. The governing agreement (OpenStreetMap Foundation
Local Chapters Agreement) does not grant any derivative rights
without additional agreement, § 7.1 Conduct.
>
> Am I missing something?
>
> Tom
>
>
>
> ___
> legal-talk mailing list
> legal-talk@openstreetmap.org <mailto:legal-talk@openstreetmap.org>
> ht

Re: [OSM-legal-talk] Brexit & EU database rights

[Simon Poole]

Am 13.12.2020 um 20:12 schrieb Tom Hummel via legal-talk:

Hi all,

Am Sonntag, 13. Dezember 2020, 15:58:48 CET schrieb Simon Poole:

The relevant bit of the directive is in article 11. As you can see the
rights are dependent on being domiciled in the EU, not on the physical
location of the "database". I would need to check up on the UK

Do the legal contributors have formed an opinion towards this, already?

Seeing the Foundation being situated in the UK, and the absence of any 
agreement acc. to art. 11 III, it looks like the foundation is loosing its 
entitlement acc. to art. 11 II of the directive.


This was the subject of the original message in this thread. The 
situation post December 31st 2020 is such that protection for sui 
generis databases will remain for database published before that date in 
the UK till the protection term runs out. In the case of OSM when the 15 
years start is naturally a bit fuzzy, but at least the reworking of the 
database in 2012 for the licence change was clearly a substantial change 
that required a significant investment by the OSMF, so it is reasonable 
to assume that protection will remain at least till September 2026 (IMHO 
there are more than enough arguments for December 2034, but I suspect 
that will be moot by 26).


Simon



German courts adhere to the „modified seat of management rule“ since 2002 (BGH 
NJW 2002, 3539), meaning some capacity to sue and be sued. OTOTH liability for 
associates is personal and unrestricted.

For Germany, it looks like there is some entitlement on behalf of FOSSGIS. The 
governing agreement (OpenStreetMap Foundation Local Chapters Agreement) does 
not grant any derivative rights without additional agreement, § 7.1 Conduct.

Am I missing something?

Tom



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




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

Re: [OSM-legal-talk] Brexit & EU database rights

[Simon Poole]

The relevant bit of the directive is in article 11. As you can see the 
rights are dependent on being domiciled in the EU, not on the physical 
location of the "database". I would need to check up on the UK 
equivalent, but it likely requires the same. Outside of the UK and EU 
(possibly including Russia), we rely on conventional copyright for 
creative works* and contract law.


Simon

* yes, I'm fully aware of the problematic bit here.

Am 13.12.2020 um 10:21 schrieb Edward Bainton:
Thank you for the link, now read. All you say on substantial changes 
makes sense.


So if we move the database into the EU, are we confident it would be 
all be protected under those terms? Does the hiatus from 1 Jan 2021 
cause any difficulties? I'm reading the bit that says protection runs 
from the date of completion of the database - which is either already 
done, or never to be achieved. Either way I'm struggling to be sure 
that a database imported into the EU (perhaps considered complete on 
the day of import?) would have the protection.


Or do we need two databases - the UK-based one that is protected under 
the legacy agreement (until the UK Parliament decides otherwise, I 
suppose), and the new EU one, and the servers work off them in tandem?


On Thu, 10 Dec 2020 at 23:18, Simon Poole <mailto:si...@poole.ch>> wrote:


To answer the questions caveat there is no relevant court
decisions that I know of, so this is all likely untested:
insubstantial changes to a database do not create a new one, but
substantial changes do. Where the line is drawn, or better where
the OSMF draws the line, is currently open. See article 10
https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex%3A31996L0009
<https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex%3A31996L0009>

Simon

Am 10.12.2020 um 22:11 schrieb Edward Bainton:

A pleasure meeting you all at LWG this evening.

I saw Brexit in the minutes for September
"At the end of year we won't be losing database rights immediately."

General guidance I've seen appears to say:
- database rights accrued before 2021-01-01 persist (as I've seen
discussed in minutes)
- database rights accrued from 2021-01-01 will exist only in the
UK (if at all: I can't see any enabling legislation after a quick
look, and this may have gone into the Govt's "later" tray - so
copyright may be the only protection).

The last point suggests to me that any edits made after
2020-01-01 will have less protection than so far has been the case.

Is that your understanding? Or is the database as a whole
protected because the architecture has been built, and subsequent
edits are protected modifications of an already-protected creation?

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

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


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


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

Re: [OSM-legal-talk] Brexit & EU database rights

[Simon Poole]

To answer the questions caveat there is no relevant court decisions that 
I know of, so this is all likely untested: insubstantial changes to a 
database do not create a new one, but substantial changes do. Where the 
line is drawn, or better where the OSMF draws the line, is currently 
open. See article 10 
https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex%3A31996L0009


Simon

Am 10.12.2020 um 22:11 schrieb Edward Bainton:

A pleasure meeting you all at LWG this evening.

I saw Brexit in the minutes for September
"At the end of year we won't be losing database rights immediately."

General guidance I've seen appears to say:
- database rights accrued before 2021-01-01 persist (as I've seen 
discussed in minutes)
- database rights accrued from 2021-01-01 will exist only in the UK 
(if at all: I can't see any enabling legislation after a quick look, 
and this may have gone into the Govt's "later" tray - so copyright may 
be the only protection).


The last point suggests to me that any edits made after 2020-01-01 
will have less protection than so far has been the case.


Is that your understanding? Or is the database as a whole protected 
because the architecture has been built, and subsequent edits are 
protected modifications of an already-protected creation?


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


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

Re: [OSM-legal-talk] Brexit & EU database rights

[Simon Poole]

Legal talk is not the LWG list if that isn't clear, that is 
le...@osmfoundation.org


Simon

Am 10.12.2020 um 22:11 schrieb Edward Bainton:

A pleasure meeting you all at LWG this evening.

I saw Brexit in the minutes for September
"At the end of year we won't be losing database rights immediately."

General guidance I've seen appears to say:
- database rights accrued before 2021-01-01 persist (as I've seen 
discussed in minutes)
- database rights accrued from 2021-01-01 will exist only in the UK 
(if at all: I can't see any enabling legislation after a quick look, 
and this may have gone into the Govt's "later" tray - so copyright may 
be the only protection).


The last point suggests to me that any edits made after 2020-01-01 
will have less protection than so far has been the case.


Is that your understanding? Or is the database as a whole protected 
because the architecture has been built, and subsequent edits are 
protected modifications of an already-protected creation?


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


OpenPGP_signature
Description: OpenPGP digital signature
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-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: [Talk-de] Flyer "Ihre Öffnungszeiten wurden zu OSM hinzugefügt"

[Simon Poole]

https://osmybiz.osm.ch/#/18/47.18682/8.39773 ist eigentlich genau dazu 
gedacht Betriebe ihren eigenen Eintrag machen zu lassen, und den auch zu 
pflegen.


Am 15.11.2020 um 08:39 schrieb Markus via Talk-de:

Am 14.11.2020 um 22:15 schrieb Frederik Ramm:


Als OSM haben wir zwar nur die besten Absichten

:-)

Gibt es denn eine Öffnungzeiten-Web-Anwendung?

Daten machen nur Sinn, wenn sie simpel nutzbar sind.
Und wenn sie aktuell sind.

Wenn sie dann "besser" sind als diejenigen anderer Anbieter
(vollständiger, genauer, aktueller)
und dies sowohl bei den Kunden, als auch bei den Ladenbesitzern ankommt,
dann könnte sowas funktionieren.

Bei den Strassen und Wegen haben wir das ja auch geschafft :-) *

Gruss, Markus

* wie ist da derzeit eigentlich der Vergleich mit dem "Wettbewerb"?


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


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

Re: [OSM-legal-talk] Data Portal License CC0 1.0 and OpenStreetMap

[Simon Poole]

Everything relevant has been documented here 
https://wiki.osmfoundation.org/wiki/Licence/Licence_Compatibility for a long 
time.

Am 6. November 2020 17:47:16 MEZ schrieb "Pierre Béland via legal-talk" 
:
> 2020-10-06 , Mateusz Konieczny wrote via legal-talk :  
>> For example Wikidata is CC0 but mostly copyright incompatible with
>OSM
>> and unusable for imports in general.
>If I understand correctly, there is quite a difference in solididy of
>license  from groups like Wikidata who import data from various sources
>vs a government agencies that produce their own data.
>
> 
>Pierre 
> 
>
>Le vendredi 6 novembre 2020 11 h 08 min 52 s UTC−5, Mateusz Konieczny
>via legal-talk  a écrit :  
> 
> See https://wiki.openstreetmap.org/wiki/Import/ODbL_Compatibility
>
>"License terms are compatible, but the licenser does not guarantee for
>it. 
>4c of the license explicitly states: "Affirmer disclaims responsibility
>for 
>clearing rights of other persons that may apply to the Work or any use
>thereof, 
>including without limitation any person's Copyright and Related Rights
>in the Work. 
>Further, Affirmer disclaims responsibility for obtaining any necessary
>consents, 
>permissions or other rights required for any use of the Work.""
>
>For example Wikidata is CC0 but mostly copyright incompatible with OSM
>and unusable for imports in general.
>
>Nov 6, 2020, 16:48 by legal-talk@openstreetmap.org:
>
>Government of Quebec has added the licence CC0 1.0 to his
>https://www.donneesquebec.ca Data portal  for import of datasets and
>never returned requests to add specific authorisation for OSM. 
>
>Looking at the history of discussions, it is not clear for me if the
>CC0 Public license is compatible with OSM. 
>
>Then my question : Does  CC0 1.0 license make the data compatible with
>OpenStreeMap Odbl llicense ?  
>
>If so, we will have access to datasets of high quality such as route,
>hydrography, address.
>
>License in french
>https://www.donneesquebec.ca/fr/licence/
>
>Deepl translation 
>---
>In order to promote collaboration, exchange and sharing, as well as the
>use of open data by all, the Government of Quebec and several
>municipalities have adopted a common licence, Creative Commons 4.0
>(CC), which comes in six variants.
>
>This licence is recognized as one of the least restrictive in terms of
>the rights to use open data, while protecting copyright.
>
>The universal Creative Commons 1.0 licence (CC0 1.0) can also be used,
>in particular to encourage the integration of data into a larger set of
>open and linked data, in which the origin of each piece of data can
>sometimes be more complex to recognise. 
>---
>
> 
>Pierre 
>
> ___
>legal-talk mailing list
>legal-talk@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/legal-talk
>  

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit Kaiten Mail gesendet.___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-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/ 
92703956 

https://www.openstreetmap.org/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-legal-talk] Is listing at Contributors page qualifying as waiver for CC BY 4.0?

[Simon Poole]

Just as a note, prior to the review of CC BY 4.0 compatibility by the 
LWG (and CC fwiw), we were very clear that 4.0 licensed material should 
-not- be imported, the importers knew this and were ignoring it at their 
own risk.


Simon

Am 23.10.2020 um 10:43 schrieb Mateusz Konieczny via legal-talk:

Is

"it is good enough for us to be named as the data owner here:
http://wiki.openstreetmap.org/wiki/Contributors#Kartverket_.28Norwegian_Mapping_Authority.29 
 
"


(see http://lists.nuug.no/pipermail/kart/2014-August/004831.html 
 for the 
original text)

sufficient to solve problems of CC BY 4.0?

As I understand CC BY 4.0 requires waiver for DRM related reasons, and 
that it would not

be sufficient.

For context see 
https://wiki.openstreetmap.org/wiki/Talk:Import/Catalogue/Road_import_(Norway) 



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


OpenPGP_0x4721711092E282EA.asc
Description: application/pgp-keys


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

Re: [talk-au] Microsoft Australian building footprints

[Simon Poole]

Just as a comment: there is nothing so time consuming as fixing badly 
mapped buildings (essentially drawing them from scratch is nearly always 
faster), I would only import building outlines that are at a quality 
level that you would not want to change them except if the building 
itself has been modified.


Simon

PS: lives in an area which had 10s of 1000s of buildings mapped already 
in 2009 from mushy misaligned yahoo imagery.


Am 20.10.2020 um 11:12 schrieb Andrew Harvey:
On Tue, 20 Oct 2020 at 18:39, Daniel O'Connor 
mailto:daniel.ocon...@gmail.com>> wrote:


and after a bit of digging came across this ODBL data:
https://github.com/microsoft/AustraliaBuildingFootprints


As fun as hand tracing data is; I'd be pretty keen to swap to
small scale imports of this, suburb by suburb in my area.

https://wiki.openstreetmap.org/wiki/Microsoft_Building_Footprint_Data

details the data in more general terms, and links to a few import
proposals.

Anyone feel like exploring and validating the quality of the data
in their areas?


Thanks for posting, I didn't realise they had released something for 
Australia. It says "The data will also be made available in Facebook 
RapiD." but I couldn't see buildings come through only roads. RapiD 
would probably be one of the easier options for bringing into OSM.


Areas which are already well mapped building wise best to leave what's 
there, and area where people are actively mapping with local knowledge 
and survey's best to leave what's there, but for general areas with 
almost no buildings mapped, I think it makes sense to manually import 
this to provide a good base level of coverage.


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


OpenPGP_0x4721711092E282EA.asc
Description: application/pgp-keys


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

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: [Talk-GB] Brexit and OpenStreetMap

[Simon Poole]

There are at least three areas which need looking at when considering 
moving the OSMF, only two of them are strictly BREXIT related:


- Sui generis database protection (this is one of the underlying 
principles our licence relies on).


- Data protection compliance (this is currently not an issue, but could 
become one).


- Corporate structure and the ease of enabling tax deductible donations 
to the OSMF (while there is a bit of an BREXIT angle to this, it is 
mainly a question of the lack of options for this in the UK that is an 
issue).


As already pointed out to Martin you can find numerous discussions and 
material on the subject here


https://wiki.osmfoundation.org/w/index.php?search=brexit=Special%3ASearch=default=1

Simon


Am 14.09.2020 um 14:51 schrieb Tony Shield:

Saw this subject in WeeklyOSM 529

 https://www.weeklyosm.eu/en/archives/13734/
Has someone analyzed the effects of Brexit on OpenStreetMap and which 
responses could be undertaken to fix potential problems?


For example have you looked at the consequences, cost and effort of 
moving the OpenStreetMap-Foundation to a EU-country and on the 
problems of staying in the UK (e.g. database protection for new 
databases by UK citizens will not be given in the EU).


Could we keep the servers in the UK but provide services under a 
different jurisdiction (because the foundation seat is moved)?


Is it possible to move the foundation, and what are the requirements? 
Maybe we should ask the membership what they would think about such a 
move? Has the board voiced its standpoint?



If something has been written about the specific situation of 
OpenStreetMap I would be interested in a link. I would also be 
interested in learning about your thoughts wrt brexit and 
OpenStreetMap. Publicly it seems we have mostly avoided any related 
considerations, until last year many had been hoping that someone 
would still stop it, but now it will become effective in only 4 months.


Cheers Martin

I'm a OSM GB member not fully understanding the structure of OSM but 
here goes -


GB is soon to be like any non-EU country. Brexit occurred 31 January 
last and Withdrawal Agreement ends 31 December 2020.


The question becomes is the OSMF so dependent on EU laws that it 
cannot operate outside the EU. OSM is a global effort and operates in 
many places where laws are substantially different to those of GB and 
EU. Laws are also different within the EU.


By thinking of moving OSMF from UK to EU because of Brexit are you 
saying that OSMF may never be able to function outside the EU - what 
about Switzerland where many international organisations are based, or 
United States. These are respected countries which should be 
considered if relocation is deemed necessary.


With respect to data privacy what is to stop OSMF mandating in its 
contracts and operation that the relevant EU data laws are adhered to. 
Maintaining data integrity and security is a function of OSMF, these 
functions are mandated by EU law, OSMF wherever it is domiciled can 
base its operations on the implementation of EU law.


With respect to current operations where OSM/OSMF operate or 
communicate outside the EU what protections are necessary?


Regards

Tony Shield

aka TonyS999


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


OpenPGP_0x4721711092E282EA.asc
Description: application/pgp-keys


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

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,  can be used to get more,  can be used to output
> up to 300 entries, _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 ,
>>
>> 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 > > 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 
>>     https://lists.openstreetmap.org/listinfo/talk
>>
>>
>>
>> -- 
>> @osm_washington
>> 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: [Talk-GB] New Bing Imagery

[Simon Poole]

There is even a (never merged and now likely really stale) PR:
https://github.com/openstreetmap/iD/pull/4166

SImon

PS: and an issue too

Am 19.08.2020 um 11:20 schrieb Mateusz Konieczny via Talk-GB:
> Have you checked whatever
> there is an open issue proposing to
> support imagery offset database in iD?
>
>
> 19 Aug 2020, 11:11 by scolebou...@joda.org:
>
> So, I followed the links below and added an offset. But this simply
> isn't a viable solution to the problem because it only works for JOSM
> and not iD.
>
> I managed to convince one mapper to type in the offset manually in iD
> every time, but that is a horrible thing to ask new mappers to do,
> very offputting. And now I can see Amazon mappers using an iD variant
> that doesn't have the offset and moving all the roads as a result:
> 
> https://osmcha.org/changesets/89549551?aoi=758c7f2b-faca-44e5-acd2-0cb8c33034bd
> https://www.openstreetmap.org/changeset/89549551
> This is going to keep happening so long as OSM has multiple image
> sources and multiple editors. Frankly I'm amazed that this isn't a
> solved problem.
>
> Having done some mapping across the country recently, it seems like
> Bing is offset to the previous best imagery across the country, but by
> varying amounts. Is there really no solution that can be applied to
> the source Bing layer? Or should we all just accept Bing as golden?
>
> Having added thousands of buildings and fixed roads to align to the
> previous best imagery, I don't have a good solution to the problem,
> and it is demotivating to think that others are going to come along
> and move individual roads/buildings to align without considering the
> bigger picture.
>
> The only solution I can think of is to move all nodes in the area I've
> worked on to match the new Bing (ie a mass edit). Any other
> suggestions?
>
> Stephen
>
>
>
>
>
>
>
>
>
>
> On Sun, 12 Jul 2020 at 23:36, Mateusz Konieczny via Talk-GB
>  wrote:
>
>
> 
> https://wiki.openstreetmap.org/wiki/JOSM/Plugins/Imagery_Offset_Database/Quick_Start
> https://wiki.openstreetmap.org/wiki/Imagery_Offset_Database
> (I think that nowadays it is built in - is plugin installation
> still necessary?)
>
>
> No idea about iD support -
> https://github.com/openstreetmap/iD/search?q=imagery+offset
>
> Jul 13, 2020, 00:21 by scolebou...@joda.org:
>
> Wow, the imagery is really good. But in my area the imagery is
> about
> 3-4m east west and 3-4m north south out of alignment with Esri
> World
> Imagery (Clarity) Beta, which is what I've been using up until now
> (for thousands of buildings).
> https://www.openstreetmap.org/#map=18/51.39886/-0.24940
>
> Is there any way to unify the alignments?
>
> Stephen
>
>
> On Thu, 9 Jul 2020 at 06:41, Gareth L  wrote:
>
>
> I’ve noticed patches of vastly improved bing imagery since
> December, but it is really patchy.
> Gareth
>
> > On 6 Jul 2020, at 23:21, Cj Malone
>  wrote:
> >
> > I was splitting houses in Portsmouth/Southsea this morning.
> The imagery
> > is great, I don't know if it was part of this update, or if
> it's been
> > like this for a while.
> >
> >
> > ___
> > Talk-GB mailing list
> > Talk-GB@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-gb
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb


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

Re: [Talk-de] Starrflügel-Drohne für Luftbilder

[Simon Poole]

Siehe auch
https://bvcp.de/multicopter-news/recht/geltungsbeginn-eu-verordnung/

Am 14.08.2020 um 14:15 schrieb Simon Poole:
> Ich gehe davon aus, dass nicht die neue, neue Drohenverodnung ist,
> sprich noch keine Anpassung an das neue Europäische Recht beinhaltet.
>
> Ich würde im Augenblick auch eher davon abraten irgendwas zu kaufen
> ausser es ist schon nach den neuen Bestimmungen zugelassen.
>
> Simon
>
> Am 14.08.2020 um 13:48 schrieb Stefan Kaufmann:
>> Am 14.08.20 um 13:18 schrieb Jo:
>>
>>> Es ist aber viel einfacher um dann die Zulassung zu bekommen. Es kann sein
>>> dass das nur wichtig ist in Belgien. Mit meines (900g) darf ich hier nur
>>> 10m hoch fliegen und das reicht ja nicht für Luftbilder.
>> Rechtslage in Deutschland ist anders:
>>
>> https://www.heli-planet.com/downloads/flyer_die_neue_drohnen_verordnung.pdf
>>
>> regards,
>> -stk
>>
>> ___
>> Talk-de mailing list
>> Talk-de@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-de
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-de


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

Re: [Talk-de] Starrflügel-Drohne für Luftbilder

[Simon Poole]

Ich gehe davon aus, dass nicht die neue, neue Drohenverodnung ist,
sprich noch keine Anpassung an das neue Europäische Recht beinhaltet.

Ich würde im Augenblick auch eher davon abraten irgendwas zu kaufen
ausser es ist schon nach den neuen Bestimmungen zugelassen.

Simon

Am 14.08.2020 um 13:48 schrieb Stefan Kaufmann:
> Am 14.08.20 um 13:18 schrieb Jo:
>
>> Es ist aber viel einfacher um dann die Zulassung zu bekommen. Es kann sein
>> dass das nur wichtig ist in Belgien. Mit meines (900g) darf ich hier nur
>> 10m hoch fliegen und das reicht ja nicht für Luftbilder.
> Rechtslage in Deutschland ist anders:
>
> https://www.heli-planet.com/downloads/flyer_die_neue_drohnen_verordnung.pdf
>
> regards,
> -stk
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-de



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

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-legal-talk] local copyright law on government data and OSM license

[Simon Poole]

This is not a particular unique situation, a sovereign country can,
naturally, create exclusive rights or specific regulation for more or
less whatever it cares.

Copyright is simply the most popular, with wide spread understanding and
international treaties as support, set of exclusive intellectual
property rights. But there is nothing stopping a government special
casing geodata or other ip that they produce, or introducing special
protection for otherwise not protected works, there can simply be no
expectation that such regulation could be internationally enforced and
reciprocal. Two examples are the national geo information law where I
live and sui generis database rights in the EU.

(Omiting some edge cases here, essentially the ones that you shouldn't
ask about, because you wont like the answer) OSM is interested in its
geodata being useful and usable globally, and because of its nature,
particulary in the country the data is relevant in. As a result, unlike
other projects, we can't ignore national quirks and restrictions and
need to accomodate them as far as it is compatible with our mission.

So in this case I would take the conservative stance (as our licence is
open and does not discriminate against commercial use) and suggest that
any use of government data would need permisson. I would not try to
outlawyer the government as your argumentation would seem to imply you
would like to do.

Naturally it is completly possible to produce a fully functional map
without resorting to government data, so not getting such permission is
not a show stopper.

tl;dr version: if you have quirky national regulations then please abide
by them so that your work contributing to OSM is not in vain. If you are
a resident in one of the edge case territories, you should read the OSMF
ToU and carefully consider your situation.

Simon

On 16.07.2020 22:59, Eugene Alvin Villar wrote:
> Hi Kathleen, all,
>
> Just as a bit of reference, the original intellectual property law
> from 1924, back when the Philippines was a territory of the United
> States, didn't have this commercial-with-prior-approval second
> sentence and was basically modeled after the U.S. law (government
> works are fully in the public domain). This additional sentence was
> added in 1972 and was retained in the present law of 1997. Previous
> analysis of the current law by Wikimedia volunteers with respect to
> copyright can be seen here and which concludes that this second
> sentence is some sort of additional non-copyright-based government
> right:
> https://commons.wikimedia.org/wiki/Commons:Deletion_requests/Template:PD-PhilippineGov
>
> This situation actually raises a lot of questions especially in the
> context of OSM. For instance, if a government agency published a
> dataset of polygons of places, it would probably be best to get the
> agency's prior approval to import such dataset in order to waive the
> requirement of "prior approval [...] for exploitation of such work for
> profit" because end users of OSM should not have to ask the agency for
> approval if they want to use the data that was included in OSM for profit.
>
> On the other hand, if an OSM mapper /derives/ new data from such a
> dataset (for example, generating a representative point for each
> polygon, maybe at the centroid, or maybe at at the "admin centre" if
> the polygon represents settlements and the mapper used their best
> judgement and research to place such points), then this new dataset is
> no longer the same as the government dataset. If the OSM mapper added
> the new derived data to OSM, then one could perhaps argue that prior
> approval from the government agency is no longer needed because the
> very act of mapping in OSM is not "for exploitation of such work for
> profit". And furthermore, end users of OSM would also perhaps not need
> to seek "prior approval" as well since they are not exploiting the
> original government dataset but rather a derived dataset (ex.,
> points), and which cannot be used to reverse engineer the original
> government dataset (ex., polygons).
>
> Regards,
> Eugene
>
>
>
> On Thu, Jul 16, 2020 at 10:57 AM Kathleen Lu via legal-talk
> mailto:legal-talk@openstreetmap.org>>
> wrote:
>
> A few thoughts:
>
> I'd want to talk to a Philippine lawyer, because frankly, these
> two sentences seem to contradict each other: /_No copyright shall
> subsist in any work of the Government of the Philippines. However,
> prior approval of the government agency or office wherein the work
> is created shall be necessary for exploitation of such work for
> profit_
> /
>
> What would be the consequences of not getting permission? A
> violation of the government's non-copyright rights? Rights of
> what? I didn't think the Philippines had database rights, but
> there could well be some other non-copyright law.
>
> Looking online, I found this on the National Mapping authority's
> website:
> Can I edit 

Re: [Talk-GB] Call to action: Translators needed

[Simon Poole]

On 14.07.2020 17:21, o...@poppe.dev wrote:
> ... again, your wording sounds like you don't trust the organizations further 
> that you could throw a rock and basically discard their efforts as those of 
> money-hungry, evil corporations that aren't interested in the humanitarian 
> aspect at all (Ablasshandel was a big thing in medieval times, I guess we 
> shouldn't go down that road).

I've never found the concept of trust when dealing with legal entities
of any kind useful. In any case the correct throwing distance would be
dropping the stone.

There is nothing wrong with being money hungry btw, leads to predictable
behaviour, and is less fickle than many other things.

>
> I know that I might be exaggerating, but in essence you're just lumping all 
> 20+ organizations together and ignore their individuality.

I'm just commenting on the involvement "in" OSM which is fairly uniform.
OK HOT seems to be pivoting now around globalizing its paid mapping
business, but that is maybe because they are wising up on the fact that
the ambulance chasing may have run its course as a funding mechanism.

In any case you should do your own research on the organizations, some
have very good reputation, say MSF, others less so.

>> A "Call to action" for MapSwipe translations just reiterates the same
>> concepts in the particular absurd situation were the issue  at hand
>> could have been resolved with a couple of minutes work at any time over
>> the last 5 years if the developers were even remotely interested in
>> cooperating with wider OSM instead of just sapping out some manpower.
> "Call to action" was _my wording_ and _my idea_ alone, nobody forced me to 
> word it that way, nor have I given it a second thought, so every criticism to 
> that reflects back to my action.
>
> If you think that the developing team could have just done/given thought "5 
> more minutes" (As a developer for 30+ years, I'm very sceptical of such 
> claims) to incorporate their project into the established areas, there's no 
> hinderance for you to get into contact (because you now know of the problem, 
> that's why nobody has done so earlier) with them, and provide an easy 
> solution to the absurdity of the situation that you see.

It essentially boils down to checking a couple of boxes in transifex and
sending an announcement out to the existing translators that there is a
new project available, and changing the base URL for the project in
whatever they use to automate translations now.

Numerous projects have done it in the past, really no big deal.

And I've suggested it to "Humanitarian" projects before (would have to
dig if it was specifically MapSwipe), but as with essentially all
"Humanitarian" software development there is essentially no cooperation
with any mainstream OSM work, which may have to do with funding, maybe not.

>
> You might have just had a bad day just like I had a couple of unpleasant 
> weeks, but I do not understand your reasoning for your reactions. That might 
> just be me and I might be completely in the wrong here, but I suggest we 
> leave it at that. 
>
> Kai

It is just experience vs. trust.

Simon


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

Re: [Talk-GB] Call to action: Translators needed

[Simon Poole]

I've been asked to clarify this as it might come across as a personal
attack which was not intended, sorry.

The, very well funded, organizations in OSM space that claim
"Humanitarian" for themselves, market themselves mainly by having a
never ending stream of emergencies (some real, some not, some where OSM
mapping could be useful, some not) that urgently need attention.

In exchange for allowing HOT, MM etc to monetize your participation in
"resolving" these emergencies, you get alleviated to a superior human
being, well at least for a while. Think of it as a digital Ablasshandel,
just that in the middle ages the benefits were probably more tangible.

A "Call to action" for MapSwipe translations just reiterates the same
concepts in the particular absurd situation were the issue  at hand
could have been resolved with a couple of minutes work at any time over
the last 5 years if the developers were even remotely interested in
cooperating with wider OSM instead of just sapping out some manpower.

Simon

On 13.07.2020 00:59, Simon Poole wrote:
> It's the other way around, I believe you are the victim and have been had.
>
> Am 12. Juli 2020 21:12:15 MESZ schrieb Kai Michael Poppe - OSM
> :
>
> On 12.07.2020 20:58, Simon Poole wrote:
>
> The project in question could have naturally joined the
> OpenStreetMap transifex organisation and profited from a
> couple of 100 very experienced translators, but that would be
> too simple. 
>
>
> Well, don't kill the messenger. I myself only today discovered that 
> there's a JOSM team and an OSM organization.
> It might be worth checking whether the projects could be moved to the OSM 
> org.
>
> Kai
> 
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
>
> -- 
> Diese Nachricht wurde von meinem Android-Mobiltelefon mit Kaiten Mail
> gesendet.
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Call to action: Translators needed

[Simon Poole]

It's the other way around, I believe you are the victim and have been had.

Am 12. Juli 2020 21:12:15 MESZ schrieb Kai Michael Poppe - OSM :
>
>On 12.07.2020 20:58, Simon Poole wrote:
>
>> The project in question could have naturally joined the OpenStreetMap
>transifex organisation and profited from a couple of 100 very
>experienced translators, but that would be too simple.
>
>Well, don't kill the messenger. I myself only today discovered that
>there's a JOSM team and an OSM organization.
>It might be worth checking whether the projects could be moved to the
>OSM org.
>
>Kai
>
>___
>Talk-GB mailing list
>Talk-GB@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-gb

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

Re: [Talk-GB] Call to action: Translators needed

[Simon Poole]

The project in question could have naturally joined the OpenStreetMap transifex 
organisation and profited from a couple of 100 very experienced translators, 
but that would be too simple.

Am 12. Juli 2020 19:50:43 MESZ schrieb Kai Michael Poppe - OSM :
>Good evening list!
>
>During last week's Missing Maps London event I got to know the mobile
>App "MapSwipe". This app is used to identify Imagery Tiles with
>specific features like buildings, roads, etc. in countries with low map
>coverage (i.e. developing/least developed countries). It is a
>second-level crowdsourcing platform and it's data is used by the
>Humanitarian OpenStreetMap Team (HotOSM.org) to feed it's taskmanager.
>From there volounteers use computer-based editors to map the tiles that
>were marked as having a mappable feature.
>
>Enough marketing talk, this is what this mail is about: The developing
>team uses Transifex
>(https://www.transifex.com/mapswipe/mapswipe-app/dashboard/) to
>translate the strings in the OpenSource-App
>(https://github.com/mapswipe/mapswipe) and is looking for people who'd
>love to contribute with more translations or finishing/reviewing the
>existing languages. Czech only needs review, but Dutch, French,
>Japanese, Nepali, Persian, Swahili, Hungarian, Indonesia, Russian and
>Spanish are still missing loads of translated strings.
>
>So, if any of you would be able to help with any of the languages
>mentioned above (you may also add any other language that you think
>should be on the app), this would be greatly appreciated!
>
>Please do not hesitate to share this mail with anyone you think could
>help or cross-post this outside this list, I haven't done so anywhere
>except the German Telegram Group t.me/OSM_de.
>
>Thank you for reading this far :)
>
>Kai
>
>___
>Talk-GB mailing list
>Talk-GB@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-gb

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

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-legal-talk] OSM Data in wikidata

[Simon Poole]

Am 16.06.2020 um 13:51 schrieb Martin Koppenhoefer:
> Am Di., 16. Juni 2020 um 13:32 Uhr schrieb Simon Poole  <mailto:si...@poole.ch>>:
>
> (not discussing if the material added is even protected
> to start with).
>
>
>
> As you are mentioning it, are you in doubt? By the substantial
> guideline it seems it would be covered by the ODbL:
> https://wiki.osmfoundation.org/wiki/Licence/Community_Guidelines/Substantial_-_Guideline

I'm simply making no assumptions about how the data got into wikidata,
for example the users may be contributing to both (OSM and WD).

Simon

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


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

Re: [OSM-legal-talk] OSM Data in wikidata

[Simon Poole]

Am 16.06.2020 um 13:13 schrieb Martin Koppenhoefer:
> 
>
> Provided that ODbL and OpenStreetMap would be sufficiently linked, is
> it then possible to copy OSM data into wikidata, which is distributed
> as CC0?
>
> 

As been pointed out many, many, many times (and it is not going to
change), CC0 explicitly does not cover third party rights in the
licensed material, just those of the entity distributing the work.

So adding information from OSM to Wikidata does not create a licence
conflict as such (not discussing if the material added is even protected
to start with).

Simon




signature.asc
Description: OpenPGP digital signature
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-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 site help.openstreetmap.org is dying
>>   (Mateusz Konieczny)
>>2. Re: our Q site help.openstreetmap.org is dying (Tom Hughes)
>>3. Re: our Q site help.openstreetmap.org is dying (Lester Caine)
>>4. Re: our Q site help.openstreetmap.org is dying (Simon Poole)
>>5. Re: our Q site help.openstreetmap.org is dying (Tobias Wrede)
>>6. Re: our Q site help.openstreetmap.org is dying (Frederik Ramm)
>>7. Re: our Q site help.openstreetmap.org is dying (Tobias Wrede)
>>8. Re: our Q 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 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 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 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-legal-talk] Legal questions about using OSM

[Simon Poole]

You are unnecessarily making your life hard. There is a big red warning
at the top of the "Use Cases" page, simply take it seriously (the
content of that page was written in 2012 a rather long time ago and
before any of the guidelines existed). The current relevant guidelines
are available from
https://wiki.osmfoundation.org/wiki/Licence/Community_Guidelines

In your specific case, as it seems you are not actually geocoding your
data (that would be extracting address or location information from OSM
with 3rd party data), that would be the Produced Work and Collective
Database guidelines.

Simon

Am 18.05.2020 um 10:10 schrieb "Birger Schütte" via legal-talk:
> Hello!
>  
> I've been studying the OSM license terms, guidelines, community pages,
> FAQs etc. for a few days now, but I'm still unsure about some of the
> statements. So I hope for your experience and would like to ask the
> following three questions:
>  
> Question 1:
> If I store calculated results based on OSM data in a database table
> (without the actual OSM data itself), such as the number of specific
> POIs, travel times, travel distances and so on - the database is then
> a collective database, a derivative database, a "produced work", or
> none of them?
> I'm not sure, because I read about
> (https://wiki.openstreetmap.org/wiki/License/Use_Cases#Case_3:_I_want_to_publish_something_based_on_OSM_and_my_own_data
> ):
> "However, if you have any data that was derived from OSM - for
> instance because you used street names from OSM, or you geocoded your
> data using the locations of roads or building shapes in OSM - then you
> are making a derivative database."
> But the Geocoding Guidelines says
> (https://wiki.osmfoundation.org/wiki/Licence/Community_Guidelines/Geocoding_-_Guideline
> ):
> "the Geocoding Results are not used to create a new database that
> contains the whole or a substantial part of the original OSM database,
> then the share-alike obligations of the ODbL are not triggered"
>  
> Question 2:
> Does the calculation of the above described results complies with the
> statement: "you geocoded your data"? Or is that not what the guideline
> means?
>  
> Question 3:
> If I reference other data with the data from this result database, do
> I have to put the referenced data under the ODBL license? For the case
> that the answer to Question 1 would be collective or a "produced work"?
> In case of derivative, I guess the database must be under ODBL...
>  
> I would appreciate any kind of help!
>  
> Kindly Regards
> birgos
>
> ___
> legal-talk mailing list
> legal-talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/legal-talk


signature.asc
Description: OpenPGP digital signature
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-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 , 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: [talk-au] Anzacathon and mapping possibilities

[Simon Poole]

At the danger of pointing out the glaringly obvious: assuming that
licence etc gets sorted out, the data is not being added in Australia,
but in other countries. If the number of imported elements is above a
handful in a country I would suggest at least giving a heads up on a
suitable country specific medium before proceeding, doing otherwise is
just going to lead to strife.

Simon




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

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(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchStandard(Launcher.java:330)
> at
> 

Re: [Talk-GB] Geospatial Commission to release UPRN/ UPSN identifiers under Open Government Licence

[Simon Poole]

It would seem to be "rather" unlikely that such reference ids would be
named UPRN and UPSN outside of the UK to start with, so a more generic
building_ref, street_ref or similar would be likely more sensible (if
there is any value at all in mapping these). And yes similar concepts
exist outside of the UK too, however I do not know any case of them
finding wide spread use in lieu of addresses any where.

Simon

Am 09.04.2020 um 16:08 schrieb Gareth L:
> Can’t the key location be inferred by the fact it is within a country bounds 
> rather than redundantly added?
>
> Gareth
>
>> On 9 Apr 2020, at 14:46, Tony OSM  wrote:
>>
>> That makes perfect sense to me.
>>
>> Any other views?
>>
>> Tony
>>
>>> On 09/04/2020 14:31, Robert Whittaker (OSM lists) wrote:
 On Thu, 9 Apr 2020 at 14:26, Robert Whittaker (OSM lists)
  wrote:
 On Thu, 9 Apr 2020 at 09:21, Tony OSM  wrote:
> If the data is to be in the public domain the next step has to be tagging.
> Do we need country specific tags for these two pieces of data?
> What should they be?
>>> [snip]
 So I'd propose that we use either ref:uprn and ref:usrn, or
 ref:UK:uprn and ref:UK:usrn. What does everyone else think?
>>> Oops. If we were to use the ISO Alpha-2 country codes, it should of
>>> course be GB rather then UK. So that would make the keys ref:GB:uprn
>>> and ref:GB:usrn .
>>>
>>> Robert.
>>>
>> ___
>> Talk-GB mailing list
>> Talk-GB@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-gb
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb



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

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: [Talk-GB] European Water Project - Introduction

[Simon Poole]

Am 14.03.2020 um 10:16 schrieb European Water Project:
> This may come through twice...
>
>
> Hi   dzidek23,
>
> What would be the workflow for adding new establishments and their
> associated tags using onosm.org  ? 
>
onosm.org simply creates notes, so less than optimal for new
establishments.

https://osmybiz.osm.ch/ will create new objects and let people manage
them in a reasonable fashion. What needs to be done is to add the
necessary keys to the presets used by the app (in this case they are in
iD format).

Simon

>
> Maybe through on the ground observation, some of the more than
> 25.000 establishments displaying a Refill UK sticker on their door
> can start being added to OSM.  The more places people know they
> can refill their reusable water bottle and avoid single-use
> plastic the better. 
>
> We are currently helping Zero Bouteilles Plastiques in France to
> add their cafés to OSM and a mapper in Bexill-On-Sea  just added
> 50 cafés from their local  scheme.   User nigelramsay
>  is looking to see
> if Refill NZ might be willing to work with OpenStreetMap in New
> Zealand.  The refill network name should be tagged with the
> drinking_water:refill:network key.which is part of the newly
> defined key namespace. 
>
> https://wiki.openstreetmap.org/wiki/Key:drinking_water:refill  
>
>
> For reference, here are some of the many regional refill schemes
> (from the drinking_water:refill wiki): 
>
>   * Australia – ChooseTap http://choosetap.com.au/
>   * Bulgaria – Zero Waste Sofia European Water
> Project https://europeanwaterproject.org/
>   * Cambodia – Refill Asia /
> RefillMyBottle https://refillasia.com/ https://refillmybottle.com/
>   * Canada – BlueW.org; Tap http://www.bluew.org/
>   * Chile – Refill (Santiago de Chile only)
>   * Europe - European Water Project https://europeanwaterproject.org/
>   * France – Refill / EU Touring (Paris only) /European Water
> Project https://refill.org.uk/ https://europeanwaterproject.org/
>   * Germany – Refill Deutschland
>   * Greece –Refill https://refill.org.uk/
>   * Hongkong – Water for Free https://waterforfree.org/en/
>   * India – BluHop https://www.bluhop.com/
>   * Indonesia – Refill Asia / RefillMyBottle https://refillasia.com/
>   * Ireland – Refill Ireland
>   * Italy – Refill / Refill Elba (Elba island only)
>   * Japan – MyMizu
>   * Laos – Refill Asia / RefillMyBottle https://refillasia.com/
>   * Luxemborg –Refill https://refill.org.uk/
>   * Switzerland – FILL IT
> UP 
> http://fillitup.ch/karte.html?fbclid=IwAR0LLkykOD92K24dgHllJtcBconZBYkM9CfrItwK4TLU7xDmdXJnRnlb-n8
>   * The Netherlands – Refill / Drinkwaterkaart / Publiek Water
>   * New Zealand – RefillNZ
>   * Thailand – Refill Asia / RefillMyBottle
>   * U.K. – Refill https://refill.org.uk/
>   * United States – Tap
>   * Vietnam – Refill Asia /
> RefillMyBottle https://refillasia.com/ https://refillmybottle.com/
>   * Worldwide – Closca https://closca.com/pages/closca-water-app
>   * Worldwide – European Water
> Project https://europeanwaterproject.org/
>
>
>
> Best regards,
>
> Stuart 
>
> On Fri, 13 Mar 2020 at 22:03, BD  > wrote:
>
> Hi,
>
> I quite like the idea of adding free water refill places to
> the OSM. One idea which could not only benefit the European
> Water Project but OSM as a whole is to add a tick box on the
> onosm.org . I could read something like "We
> do provide free water refills" - link to European Water
> Project. If we would promote the onosm.org 
> a bit more not only numbers of businesses aware of/on OSM
> would increase, + people aware of Water Project. Water Project
> volunteers (if there are any) could direct businesses to
> onosm.org  for ease of adding info, this way
> we would "kill two birds with one stone" - as we say where I
> come from.
>
> cheers,
> dzidek23
>
>
>
>
>  
>
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb


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

Re: [Talk-GB] European Water Project - Introduction

[Simon Poole]

Peter I don't believe there is/are any active moderators at this point.
The UK community should nominate one or more, and ask the OWG to instate
them as list moderators. In any case pleading to them here will not work
(and likely wouldn't work even if there were some).

Simon

Am 13.03.2020 um 23:37 schrieb Peter Neale via Talk-GB:
> List Moderators,
>
> Please remove @Daniel Holsey from this list.  His contribution will
> not be missed.
>
> Regards,
> Peter
>


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

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
>> fun, option, is to simply block a

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 around 70-80%
>&g

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, > > 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
>> ?
>>
>> 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/ 
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
>> :
>>
>> 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
>> communities, but just