Re: [OSM-talk] Help me build an OSM Community Index

[Johannes Singler]

Hi,

I think this is a great idea for community building.

BTW what about having similar functionality *during* editing?  For 
example showing a link to the OSM wiki page of the currently edited area?
Such pages often tell what to pay special attention to in a certain 
area, but IMHO they would deserve more visits (which could be improved 
by showing such links).


Johannes

Am 31.03.2018 um 14:25 schrieb Bryan Housel:

I’ve started building an index of OSM community resources here:
https://github.com/osmlab/osm-community-index

"Resources" can be links to forums, meetups, Slack groups, Facebook 
groups, mailing lists, and so on. Anything that mappers, especially 
beginners, might find interesting or helpful.


*Why?*

Currently when you save an edit in iD, you will see a screen prompting 
you to share your edit on Facebook, Twitter, Google+.  But we’d prefer 
instead to use this screen to let the user know more about the community 
around where they are editing.


See https://github.com/openstreetmap/iD/issues/4815  for discussion and 
some mockups.


While the initial use of this index will be primarily to support this iD 
feature that will be released soon, I’d love to see other applications 
that have a community focus use the index as well.  For example, if you 
are reviewing an edit in OSMCha, and you see something that looks like 
vandalism or an undiscussed import and you want to ask someone in the 
local community to take a look, this index could tell you how to reach 
out to somebody local.



*What about { existing lists / the OSM wiki }?*

I did look at existing community lists, and there are several, but most 
of those lists do not support adding a bounding polygon around a 
community.  Several of them do let you place a single pin where the 
community is, but I was looking for something that would let me draw 
complex bounding areas, and filter to only show communities active 
around in the area where a user is editing.


We already have a successful project for sharing imagery sources that 
editors can use (see https://github.com/osmlab/editor-layer-index ) so I 
decided to create something very similar.



*How can I help?*

Glad you asked!
1.  Go to https://github.com/osmlab/osm-community-index/  and watch or 
star the project. ⭐️


2.  Read the README and CONTRIBUTING documents.  These contain info 
about which files need to be added:


  * Each resource needs a `.json` file to describe it, and
  * a `.geojson` file to describe where the region where it is active.
  (multiple resources can share a .geojson file)


3.  Either add the files with a Pull Request, or open an issue for 
somebody else to add the files.



Thanks!
Bryan






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



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

Re: [OSM-talk] Sidewalk symmetry

[Andrew Harvey]

On 18 April 2018 at 06:30, Jmapb  wrote:

> (My personal feeling is that that it's better to avoid mapping sidewalks
> as separate ways unless there's a compelling reason that would outweigh the
> additional data clutter and routing complications. In some circumstances --
> those where walking on the sidewalk, or on a particular side of a road with
> two sidewalks, has noticeably different routing implications -- it seems
> like a good idea.)
>

It means less tags on the road which makes it easier to edit manually. A
road already has:

highway, surface, maxspeed, maxweight, maxheight, width, oneway, access,
lanes, turn:lanes, lit, parking:lane:left, parking:lane:right,
parking:condition:left, parking:condition:right,parking:lane:left:type,
parking:lane:right:type, etc.

A sidewalk also has it's own:

maxspeed (some places where bicycles can use the sidewalk and sections have
signposted speed), maxweight, width, access, surface

On top of that the highway needs to be split every time just one of those
tags changes meaning you end up with many short segment ways.

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

It means we can use say the exact same tags on the separate sidewalk rather
than prefixing them with sidewalk:left:width, sidewalk:left:bicycle, etc.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Sidewalk symmetry

[Jmapb]

The wiki contains some suggestions/guidelines about when to map 
sidewalks as separate footways versus when to encode them as tags on the 
main road. The basic recommendation seems to be that if there's a 
barrier or even a strip of grass between the two, a separate way is fine 
and even sometimes preferred (and the road should be tagged 
sidewalk=separate to indicate that it's been mapped as a separate way), 
but if the sidewalk is directly adjacent to the road, better to just 
imply it with a sidewalk=left/right/both tag.


My gut tells me that a corollary should be: If the sidewalk on one side 
of the road is mapped as a separate way, then the sidewalk on the other 
side (if there is one) should also be a separate way, even if it's 
directly adjacent to the road due to asymmetry of sidewalk design. Does 
this sound right? I certainly don't see any clean way to tag a road to 
indicate that one of its sidewalks has been mapped as its own way and 
the other hasn't.


(My personal feeling is that that it's better to avoid mapping sidewalks 
as separate ways unless there's a compelling reason that would outweigh 
the additional data clutter and routing complications. In some 
circumstances -- those where walking on the sidewalk, or on a particular 
side of a road with two sidewalks, has noticeably different routing 
implications -- it seems like a good idea.)


Thanks for you thoughts, jmb


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

Re: [OSM-talk] GDPR introduction

[Simon Poole]

Am 17.04.2018 um 19:37 schrieb Michael Reichert:
> 
> *Controller vs. processor*
>
> Chapter "Recommendations", section 3 (page 10) writes:
>> Using the data for user and contribution profiling will either require a data
>> processing agreement (and a similar agreement for research) or the the OSM
>> data consumer needs to operate as an independent data controller (see
>> below)..
> Does this mean that someone who runs a service to fight vandalism and
> other bad edits has the choice to either sign a data processing
> agreement with the OSMF or to work as independent data controller? I am
> not sure because section 5 on the same page writes:
There are essentially 3 routes that we could take:
 
- not distribute meta-data to third parties at all (sure to be very
popular :-))
- a controller - data processor type arrangement. Besides the construct
being a bit contrived in our case, the typical data-processing
agreements I've seen are rather large legal monsters that are not going
to be easy on anybody, but we are not going to rule this completely out,
at this point in time-
- the entities processing the data are doing so on their own behalf and
are acting as independent controllers (which is more what is really
going on in any case)

>> Entities receiving full data (that is including metadata) are expected to 
>> operate as
>> independent controllers.
> Working as data processor has the disadvantage that the service provider
> has to sign some piece of paper. 
A DPA is definitely not some piece of paper :-) (make that 10+)
> On the other hand it provides safety
> for them. If a service provider acts as data controller any OSM user can
> ask him to delete his user data?

Well that depends on the reasoning the controller uses to document that
the processing of personal data is "lawful", as the data hasn't directly
been obtained from the data subject you will not be able to rely on
consent as a basis, but likely similar legitimate interests arguments
could be made as the OSMF will likely do (vandalism protection, QA, and
so on).

> Users asking the service providers instead of the OSMF to delete their
> data add addition hassle to the service provider and harm the
> development of OSM:
>
> - The service provider has to "filter" incoming data from OSM (diffs,
> planet dump, …) to remove data they are not permitted to use.
>
> - The community is unable to review edits of that user using the
> third-party service because the user is not visible there. Users with
> bad faith (they exist and I know a few examples) can use that to do
> edits below the radar and make validation and reverts of their edits
> difficult.

We intend to provide a list of "deleted users" or rather user ids so
this shouldn't be all to difficult, but the entities processing the data
will need to make their own determination on how to handle the deletions.

>
> That's why I would like to ask the OSMF to let service providers choose
> their favourite legal model. If the service provider chooses to be a
> data processor, he can redirect incoming request of deletion to the OSMF
> and the OSMF has to delete the user and block his account. The latter
> makes further validation of his edits mostly unnecessary.
>
>
> *Timestamps*
>
> Appendix B writes:
>> It can be argued that completely removing timestamps causes a significant 
>> loss of
>> functionality and information, for example when an object was last updated. 
>> This
>> could be partially rectified by simply reducing the granularity of the 
>> timestamps in
>> publicly available data, for example by only displaying dates.
> Removing user names, user IDs and changesets from data dumps and general
> API access does not really harm most usage of OSM. However, one change
> might cause more trouble if it were seriously followed through – the
> timestamps.
>
> If you reduce their granularity to one day, it is still possible to
> group edits in areas with a low density of mappers. I am not talking
> about central Sahara, the poles or the Middle West of the U.S. I am
> talking about almost all areas of Central and Western Europe except the
> metropolitan areas.
>
> See the following picture of my master thesis
> https://user-images.githubusercontent.com/3611273/36112876-50bbe552-102b-11e8-9857-23b868017013.png
>
> It shows the frequency of map edits in the north-east of Germany between
> 2016-08-29 and 2016-10-05. Edits on relations have been ignored. I
> imported the hourly diffs from OSM into my database. Dark blue means
> that within more than one month, less than four diffs contained updates
> for that area. You would have to reduce the granularity to a month to
> make the recreation of changesets impossible!
>
> Slide 15 of
> http://tib.flowcenter.de/mfc/medialink/3/de416ce499d2c0ef194390304b67c5a08d22fbd5cff5af05bd6931d24f4016b2b9/FOSSGIS2017-5147-qualitatssicherung_mit_vektortiles.pdf
> shows the same for California. It is possible to group edits in the Bay
> Area if the granularity is red

Re: [OSM-talk] GDPR introduction

[Michael Reichert]

Hi Simon,

Am 2018-04-17 um 12:48 schrieb Simon Poole:
> On the 25th of May 2018 the *General Data Protection Regulation (GDPR)
> * will
> enter in to force, this will likely result in some changes in how
> OpenStreetMap operates and distributes its data.
> 
> The LWG has prepared a position paper on the matter that has been
> reviewed by data protection experts and in general the approach to not
> rely on explicit consent has been validated. It should be noted that
> while the paper outlines our approach, some of the details still need to
> be determined. In particular the future relationship with community and
> third party data consumers that utilize OSM meta-data and what will
> actually be dropped/made less accessible of the data listed in Appendix B.
> 
> LWG GDPR Position Paper
> 
> 
> Please feel free to discuss on the talk page
>  or on this list.

I would like to thank you for your work and agree that the OSMF should
not ignore GDPR. I think that it is a huge step forwards in terms of
data protection in general.

*Controller vs. processor*

Chapter "Recommendations", section 3 (page 10) writes:
> Using the data for user and contribution profiling will either require a data
> processing agreement (and a similar agreement for research) or the the OSM
> data consumer needs to operate as an independent data controller (see
> below)..

Does this mean that someone who runs a service to fight vandalism and
other bad edits has the choice to either sign a data processing
agreement with the OSMF or to work as independent data controller? I am
not sure because section 5 on the same page writes:
> Entities receiving full data (that is including metadata) are expected to 
> operate as
> independent controllers.

Working as data processor has the disadvantage that the service provider
has to sign some piece of paper. On the other hand it provides safety
for them. If a service provider acts as data controller any OSM user can
ask him to delete his user data?

Users asking the service providers instead of the OSMF to delete their
data add addition hassle to the service provider and harm the
development of OSM:

- The service provider has to "filter" incoming data from OSM (diffs,
planet dump, …) to remove data they are not permitted to use.

- The community is unable to review edits of that user using the
third-party service because the user is not visible there. Users with
bad faith (they exist and I know a few examples) can use that to do
edits below the radar and make validation and reverts of their edits
difficult.

That's why I would like to ask the OSMF to let service providers choose
their favourite legal model. If the service provider chooses to be a
data processor, he can redirect incoming request of deletion to the OSMF
and the OSMF has to delete the user and block his account. The latter
makes further validation of his edits mostly unnecessary.


*Timestamps*

Appendix B writes:
> It can be argued that completely removing timestamps causes a significant 
> loss of
> functionality and information, for example when an object was last updated. 
> This
> could be partially rectified by simply reducing the granularity of the 
> timestamps in
> publicly available data, for example by only displaying dates.

Removing user names, user IDs and changesets from data dumps and general
API access does not really harm most usage of OSM. However, one change
might cause more trouble if it were seriously followed through – the
timestamps.

If you reduce their granularity to one day, it is still possible to
group edits in areas with a low density of mappers. I am not talking
about central Sahara, the poles or the Middle West of the U.S. I am
talking about almost all areas of Central and Western Europe except the
metropolitan areas.

See the following picture of my master thesis
https://user-images.githubusercontent.com/3611273/36112876-50bbe552-102b-11e8-9857-23b868017013.png

It shows the frequency of map edits in the north-east of Germany between
2016-08-29 and 2016-10-05. Edits on relations have been ignored. I
imported the hourly diffs from OSM into my database. Dark blue means
that within more than one month, less than four diffs contained updates
for that area. You would have to reduce the granularity to a month to
make the recreation of changesets impossible!

Slide 15 of
http://tib.flowcenter.de/mfc/medialink/3/de416ce499d2c0ef194390304b67c5a08d22fbd5cff5af05bd6931d24f4016b2b9/FOSSGIS2017-5147-qualitatssicherung_mit_vektortiles.pdf
shows the same for California. It is possible to group edits in the Bay
Area if the granularity is reduced to one day.

I agree that timestamps can be used to group edits but it is not
possible to group them properly and you still don't know who uploaded
the changeset. That's where personal information begin

Re: [OSM-talk] GDPR introduction

[Ed Loach]

Andrew asked:

> Yes that does help clarify my concerns too. I still wonder if someone 
> outside the EU can go ahead and publish the full metadata included 
> OSM database under the ODBL outside the OSMF, or in the worst case 
> local communities outside the EU can still publish their regional extracts 
> with metadata publicly.

I am not a lawyer, but a quick Google search suggests the answer is no, as the 
legislation applies based on the data subject being in the EU, not the 
processor - see for example "Why non-EU companies should care" in 
https://econsultancy.com/blog/69282-how-should-non-eu-businesses-prepare-for-the-gdpr

Ed


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

Re: [OSM-talk] GDPR introduction

[Christoph Hormann]

On Tuesday 17 April 2018, Andrew Harvey wrote:
>
> Yes that does help clarify my concerns too. I still wonder if someone
> outside the EU can go ahead and publish the full metadata included
> OSM database under the ODBL outside the OSMF, or in the worst case
> local communities outside the EU can still publish their regional
> extracts with metadata publicly.

Well - that is obviously a question you need to get qualified local 
legal advise on.  Same as if you can publicly distribute a copy of 
.

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

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

Re: [OSM-talk] GDPR introduction

[Andrew Harvey]

On 17 April 2018 at 23:31, Christoph Hormann  wrote:

> On Tuesday 17 April 2018, Simon Poole wrote:
> >
> > > * When you add new 'terms of use' or 'data processing agreement'
> > > provisions that people who want to access OSM data with metadata
> > > need to agree to does that constitute an amendment of the ODbL and
> > > therefore a change in license?  If not would any downstream data
> > > user who distributes a derivative database be allowed to add
> > > similar terms of use that restrict use of the data to the data they
> > > distribute?
> >
> > As the mail said, the exact details are not nailed down there yet,
> > however it is likely that we will not want to enter in to an
> > agreement with such people, but would simply offer to help with their
> > obligations from Art. 14. It is not as if the GDPR suddenly
> > disappears when we distribute data on ODbL terms so people processing
> > the full dataset are going to be subject to it in any case.
>
> Ok - that is much clearer (and IMO also addresses what Andrew wondered
> about).  If it is sufficient for the GDPR to (a) not have technically
> unrestricted access and (b) make sure everyone receiving the data is
> made aware of the legal obligations that seems something that can be
> reasonably dealt with.
>
> The terminology used in the position paper however seems to point into a
> somewhat different direction (i.e. that providing bulk metadata would
> be subject to a specific contractual agreement).


Yes that does help clarify my concerns too. I still wonder if someone
outside the EU can go ahead and publish the full metadata included OSM
database under the ODBL outside the OSMF, or in the worst case local
communities outside the EU can still publish their regional extracts with
metadata publicly.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] GDPR introduction

[Christoph Hormann]

On Tuesday 17 April 2018, Simon Poole wrote:
>
> > * When you add new 'terms of use' or 'data processing agreement'
> > provisions that people who want to access OSM data with metadata
> > need to agree to does that constitute an amendment of the ODbL and
> > therefore a change in license?  If not would any downstream data
> > user who distributes a derivative database be allowed to add
> > similar terms of use that restrict use of the data to the data they
> > distribute?
>
> As the mail said, the exact details are not nailed down there yet,
> however it is likely that we will not want to enter in to an
> agreement with such people, but would simply offer to help with their
> obligations from Art. 14. It is not as if the GDPR suddenly
> disappears when we distribute data on ODbL terms so people processing
> the full dataset are going to be subject to it in any case.

Ok - that is much clearer (and IMO also addresses what Andrew wondered 
about).  If it is sufficient for the GDPR to (a) not have technically 
unrestricted access and (b) make sure everyone receiving the data is 
made aware of the legal obligations that seems something that can be 
reasonably dealt with.

The terminology used in the position paper however seems to point into a 
somewhat different direction (i.e. that providing bulk metadata would 
be subject to a specific contractual agreement).

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

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

Re: [OSM-talk] GDPR introduction

[Andrew Harvey]

Thank you those in the LWG that have put this paper together. My thoughts
are OSM's ODBL license grants me the right to publish a version of
http://hdyc.neis-one.org/ open to the public, not restricted to OSM users.
Reading this, I understand the OSMF is proposing to introduce Terms of Use
which take away my rights to use the OpenStreetMap data in ways that were
okay last month, in order to comply with an EU specific law. Would that
eliminate all options for someone outside the EU to publish something like
http://hdyc.neis-one.org/ but open to the public?

On 17 April 2018 at 20:48, Simon Poole  wrote:

> On the 25th of May 2018 the *General Data Protection Regulation (GDPR)
> * will
> enter in to force, this will likely result in some changes in how
> OpenStreetMap operates and distributes its data.
>
> The LWG has prepared a position paper on the matter that has been reviewed
> by data protection experts and in general the approach to not rely on
> explicit consent has been validated. It should be noted that while the
> paper outlines our approach, some of the details still need to be
> determined. In particular the future relationship with community and third
> party data consumers that utilize OSM meta-data and what will actually be
> dropped/made less accessible of the data listed in Appendix B.
>
> LWG GDPR Position Paper
> 
>
> Please feel free to discuss on the talk page
>  or on this list.
>
> Simon
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] GDPR introduction

[Simon Poole]

Am 17.04.2018 um 14:14 schrieb Christoph Hormann:
> On Tuesday 17 April 2018, Simon Poole wrote:
>
>> LWG GDPR Position Paper
>> 
>>
>> Please feel free to discuss on the talk page
>>  or on this list.
> A number of questions/comments:
>
> * Is there some sort of document outlining the data retention practice 
> for user logins on the OSM website which according to your suggestion 
> would be the basis of granting access to metadata in the future.  
> Obviously some level of retention of such data is permitted (for abuse 
> prevention etc.) but it would be nice to know how long and in what form 
> such data is retained.  This is not directly related to the GDPR but 
> would become increasingly relevant if functionality on the OSM website 
> is more often subject to being logged in.
Currently there is no formal policy on how long the logs for
openstreetmap.org are retained as far as I know, but it is one of the
things that should be documented.
>
> * I am not completely sure about the view of the LWG regarding the 
> question if the geodata itself (that is geometries, tags and IDs of 
> nodes, ways and relations) contains personal data according to the 
> GDPR.  Your recommendations seem to indicate you think it does not but 
> that is not necessarily self-evident.  Note i am not talking about 
> special cases here where mappers add personal data (like names of 
> people living in a house) although they should not, i am talking about 
> normally mapped stuff where you could identify individual mappers from 
> tagging and geometry characteristics and based on timing derived from 
> feature IDs.
We don't have a formal view on the pure geographic data itself, but are
naturally aware that taken to extremes it could be analysed the way you
suggest.
>
> * When you add new 'terms of use' or 'data processing agreement' 
> provisions that people who want to access OSM data with metadata need 
> to agree to does that constitute an amendment of the ODbL and therefore 
> a change in license?  If not would any downstream data user who 
> distributes a derivative database be allowed to add similar terms of 
> use that restrict use of the data to the data they distribute?
As the mail said, the exact details are not nailed down there yet,
however it is likely that we will not want to enter in to an agreement
with such people, but would simply offer to help with their obligations
from Art. 14. It is not as if the GDPR suddenly disappears when we
distribute data on ODbL terms so people processing the full dataset are
going to be subject to it in any case.

>
> * Your position paper does not seem to mention the OAuth service - it 
> seems to me registering an application to use this in the current form 
> would also need to require a special agreement.  In addition it might 
> be a good idea (i think i suggested this already in the past) to 
> provide an anonymous OAuth service - where the application using it 
> gets confirmation that the user is logged in as an registered OSM user 
> but which does not provide any information on this user's identity.
>
Well such an app can only access the data of the user that authorized
its access and even so not anything particularly critical (for example
it currently doesn't have access to the e-mail address), but it is clear
that there is opportunity for harvesting some data there. But in any
case this is more a question of if we want to validate apps in general
that access OSM or not, which in turn would imply blocking non-validated
ones and so on..

Simon



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

Re: [OSM-talk] GDPR introduction

[Christoph Hormann]

On Tuesday 17 April 2018, Simon Poole wrote:

>
> LWG GDPR Position Paper
> 
>
> Please feel free to discuss on the talk page
>  or on this list.

A number of questions/comments:

* Is there some sort of document outlining the data retention practice 
for user logins on the OSM website which according to your suggestion 
would be the basis of granting access to metadata in the future.  
Obviously some level of retention of such data is permitted (for abuse 
prevention etc.) but it would be nice to know how long and in what form 
such data is retained.  This is not directly related to the GDPR but 
would become increasingly relevant if functionality on the OSM website 
is more often subject to being logged in.

* I am not completely sure about the view of the LWG regarding the 
question if the geodata itself (that is geometries, tags and IDs of 
nodes, ways and relations) contains personal data according to the 
GDPR.  Your recommendations seem to indicate you think it does not but 
that is not necessarily self-evident.  Note i am not talking about 
special cases here where mappers add personal data (like names of 
people living in a house) although they should not, i am talking about 
normally mapped stuff where you could identify individual mappers from 
tagging and geometry characteristics and based on timing derived from 
feature IDs.

* When you add new 'terms of use' or 'data processing agreement' 
provisions that people who want to access OSM data with metadata need 
to agree to does that constitute an amendment of the ODbL and therefore 
a change in license?  If not would any downstream data user who 
distributes a derivative database be allowed to add similar terms of 
use that restrict use of the data to the data they distribute?

* Your position paper does not seem to mention the OAuth service - it 
seems to me registering an application to use this in the current form 
would also need to require a special agreement.  In addition it might 
be a good idea (i think i suggested this already in the past) to 
provide an anonymous OAuth service - where the application using it 
gets confirmation that the user is logged in as an registered OSM user 
but which does not provide any information on this user's identity.

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

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

Re: [OSM-talk] External contact channels and GDPR

[Simon Poole]

Isn't this a bit a "what if"?

Definitely the OSMF is not requiring or asking anybody to discuss topics
on media that are not operated by the foundation and as you know
provides a variety of options (changeset comments, diaries, mailing
lists and forums) that can be used without involving third parties. iD
now suggests options that are not OSMF operated, but that content is not
curated by the OSMF.

Further the intro to the privacy policy actually touches on the issue
https://wiki.osmfoundation.org/wiki/Privacy_Policy

Simon

Am 17.04.2018 um 07:51 schrieb Andrew Hain:
> The issue would be that we are asking someone to trust an external
> provider. At worst we could be responsible for propagating their
> noncompliance with the GDPR.
>
> --
> Andrewm
> 
> *From:* Kathleen Lu 
> *Sent:* 16 April 2018 23:11:11
> *To:* Andrew Hain
> *Cc:* talk@openstreetmap.org
> *Subject:* Re: [OSM-talk] External contact channels and GDPR
>  
> Hi Andrew,
> It's not clear to me why GDPR would make it unacceptable in general to
> ask someone to discuss something, whether a controversial edit or not,
> in one forum or another, OSMF or not. What would be the concern?
> -Kathleen
>
>
> On Mon, Apr 16, 2018 at 9:18 PM Andrew Hain
> mailto:andrewhain...@hotmail.co.uk>> wrote:
>
> When we ask mappers to discuss controversial edits or imports is
> it ever acceptable under GDPR to direct people to a contact
> channel that is not directly run by the OSMF?
>
> --
> Andrew
> ___
> 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

[OSM-talk] GDPR introduction

[Simon Poole]

On the 25th of May 2018 the *General Data Protection Regulation (GDPR)
* will
enter in to force, this will likely result in some changes in how
OpenStreetMap operates and distributes its data.

The LWG has prepared a position paper on the matter that has been
reviewed by data protection experts and in general the approach to not
rely on explicit consent has been validated. It should be noted that
while the paper outlines our approach, some of the details still need to
be determined. In particular the future relationship with community and
third party data consumers that utilize OSM meta-data and what will
actually be dropped/made less accessible of the data listed in Appendix B.

LWG GDPR Position Paper


Please feel free to discuss on the talk page
 or on this list.

Simon



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