[OSM-talk] Fwd: Automated edit for name inconsistencies

[Marc_marc via talk]

Forward of a AE review for approval send wrongly on tagging mailing

 Message transféré 
Sujet : [Tagging] Automated edit for name inconsistencies
Date : Sun, 29 Sep 2024 19:00:10 +0200
De : Kai Michael Poppe - OpenStreetMap 

Pour : tagg...@openstreetmap.org

As posted on the community discourse, this is a cross-post.

I propose to do an automated edit as described here:

https://wiki.openstreetmap.org/wiki/User:Kmpoppe/Automated_Edits/Fix_Name_Inconsistencies

For documentation purposes, please discuss or approve on the wiki page, 
thanks!


Kai



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

[OSM-talk] Fwd: FW: [EXTERNAL] Re: ODbl concerns

[john whelan]

Apols to Allen, the message was too large with the old stuff on the end and
I forwarded it to the talk ca list by mistake.


-- Forwarded message -
From: john whelan 
Date: Thu, 24 Aug 2023 at 14:04
Subject: Re: FW: [EXTERNAL] Re: [OSM-talk] ODbl concerns
To: George Boulos (DTP) 
Cc: talk@openstreetmap.org , Robert C Potter (DTP) <
robert.pot...@roads.vic.gov.au>, Priya Maniam Chinakarapaya (DTP) <
priya.maniamchinakarap...@roads.vic.gov.au>


I was probably what you might call a glue person in the project. I was
interested in importing bus stops with the phone number to call for the
next bus in Ottawa to the map.

The new minister in charge of Treasury Board wanted to shake hands with
Open Data people.  So a group of a dozen of us got selected to attend.  The
most important people there were not the minister but his staff and when I
mentioned we couldn't use their open data because of the license they asked
me to repeat the statement and they listened.  Later they went on to talk
to other open data consumers. It took five years for their license to be
changed to something that looked like we could use.  In Canada we have a
long history of importing CANVEC data into the map.  The number of mappers
per square kilometer is much lower than say Germany.

In Ottawa we were very lucky in having a University lecturer who was into
Open Data and she was instrumental in many ways in forwarding the agenda.

I'd retired from Statistics Canada but knew their corporate culture quite
well.  It was about the time when the new license was approved, that they
decided to create a project about buildings.  The pilot would take place in
Ottawa seeing it was local and one of their staff had seen OpenStreetMap
and thought this was a great way that they could crowd source adding more
information about buildings.  They'd seen a building added with iD and
thought it would be simple.  This they would combine with other data and
sell to clients.

I drank my first cup of coffee of many with the project manager and
suggested it might be an idea to have a meeting to see if data could be
imported.  The new Federal government's Open Data licence looked as if it
matched OSM's licensing requirements so it looked sort of doable and
Metrolink had recently been adding addresses.  Metrolinx is a transit
organisation in Ontario and by adding addresses into OSM they hoped newly
occupied addresses could make use of route planning applications.

We had a meeting, City of Ottawa, myself, someone from Metrolinx who had
imported addresses from a Stats Canada source into OSM, they were there on
the phone, we had someone from HOT in Switzerland describing how HOT used
crowdsourcing to add data to OSM, the University lecturer who brought up
bilingualism, I had a Nexus running OSMAND in French displaying the Ottawa
street names in French and that probably sealed the deal as bilingualism is
mandatory and expensive in the Canadian civil service.  The lecturer
identified a dataset that the city of Ottawa owned and that became the data
set that would be later imported. The Stats Canada director who was at the
meeting said we'd turned the project into something quite different.

The City of Ottawa would need to change their license to align with the new
Federal one, that had to go to council but was eventually approved after a
delay of about a year.

The civil service and OSM are very, very different cultures.  The open data
would be imported by local mappers but only if they decided they would go
ahead.  We had two major targets in OSM, the locals and the heavies. Stats
had money so I suggested that the project manager attend SotM in europe.
Unfortunately at the last minute he was unable to attend but fortunately
his boss was and he met with a number of what I'd call the heavies of OSM.

The project manager and his assistant were dispatched to meet with the
local mappers and buy them coffee and flesh out the details.  We had a
group of enthusiastic mappers around, James was one of them.  They had a
half dozen physical meetings over coffee and agreed the import could go
ahead and that the local  OSM mappers would do it.

OSM has had a lot of substandard data imported into it over time so there
are now procedures to follow before importing the data.  Many mappers in
OSM, especially in Europe, don't exactly love data being imported and their
views are made known in the import process.  Getting approval to import is
not easy and dealing with the people involved was not easy either. You
can't just import, you have to have a process to deal with existing data in
the map. I'd have someone else do it.

The license was challenged. It would need to go to the Legal Working Group
for a benediction.  Their backlog was about three years.  However Mapbox
and others had heard about the project at the SotM and were interested.  I
understand one of their employees was a member of the LWG.  Somehow we got
the license approved for an import.  This is why the advi

[OSM-talk] Fwd: Call to Take Action and Confront Systemic Offensive Behavior in the OSM Community

[Celine Jacquin]

Hello everyone
Thank you for your answers.

And thanks for the supportive messages.

I will give a general response, trying to cover all the points that I can
extend, and trying to be clear despite my limited time and fluency in
English.

Above all, I would like you to become aware of the harshness of the
responses that reach me when directing myself to myself, when this
initiative is collective, and is that of a large number of women who are
already confronting and documenting, researching, have been analyzing and
drawing on testimonies for many years now (see the main mission of
Geochicas, the context in which this community was formed; see also the
different initiatives and activities in different countries of our fellow
signatories).
The responses in the regional chats, since yesterday, have reached varying
levels of sometimes intolerable discrimination, and also a general effort
to deflect the problem that we raise by pointing out all the details, flaws
in our declaration (made in 1 day between people who have already a great
workload, because no, a large number of us are not people from the
privileged circle of corporations closely linked to OSM located in rich
countries, a common criticism in chats).
Many members of Geochicas testified that they did not have the energy to
take part in the debate on lists and chats, because of the level of
aggressiveness that can be seen there.

This to come back to the point already shared many times in all possible
communication channels: women, from southern countries, OSM members, are
materially limited to participate in all the activities that we would like,
in particular the activities of high levels such as participating in the
board, and animatedly limited by aggressiveness of any type, direct or
indirect, frontal or underlying, in all types of communication.

Reading the reactions to our initiative since yesterday, as well as the
numerous invitations to make my own copy of OSM and leave it (we will
document these comments in an organized way for those who do not believe
it), demotivated me to participate in the board meeting today, and affected
for the next few days surely, but also, deeply disappointed by what I
generally experience as a beautiful commitment and a nice community (when I
participate little in the debates and do not realize what is happening
there).

Some concrete points to your answers:

- Directly targeting a person who expresses herself clearly on behalf of a
community, deliberately mistaking the interlocutor, is equivalent to
looking for a target rather than establishing a dialogue.

- Our statement is not a direct and personal reaction to Frederick's email.
His email is simply an incident that motivates us to react again, in a new
way, in the continuity of our different actions on this same line. Nothing
to do with a strategy of avoiding the theme of the entry of representatives
of Facebook to the board. Nothing personal either. We are all convinced
that an individual who makes unfortunate choices in his expression (this
also happens to anybody and we strive to recognize it), can also be a
valuable member of OSM. This does not change our point at all.

- We are not talking specifically about quotas, we invite the OMSF to think
collegially about solutions and to integrate various people in the search
for a solution, by adapting to the limits of these people to be able to
participate in it also (therefore seek real solutions to the participation).

- We did not have time in 1 day to think of the right support to share this
statement. Google is clearly not a good solution. The statement shared
yesterday due to the board meeting is a draft, it will then (very soon) be
posted on the wiki.

- As has already been said, you cannot explain to a perpetually offended
group, which expresses it as such, that the remarks which offend them are
not offensive. If a person is offended, it is because the terms of
collective expression must be reviewed. Without it, you assume without
saying it that you do not want to give voice or take into account what
these people are telling you and what they are experiencing.

- Diversity is clearly a large and complex issue, and we all fail at one
level or another. But working to improve diversity means being open to
petitions and always improving our rank of understanding it. Criticizing
the search for diversity by demonstrating the limits of others is what I
can call: sabotaging this search for diversity.
The correct way is to always humbly re-read our own words when someone
points out an offense.
Considering the fact of not offending anyone in such a large community
utopian, would that be a way of saying that it is pointless and useless to
work to improve the inclusiveness of our modes of expression? Is there an
excuse to continue to be violent on any scale without limit? I also believe
that it's hard not to offend anyone and to understand everyone's codes, but
the secret to the recipe lies in *being willing and try

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

[80hnhtv4agou--- via talk]

I tried but many conflicts appeared in JOSM I'm not experienced to do it. 
Please if someone can do it. It's not only this 3 changeset but most of that 
user.  
>>Saturday, October 24, 2020 10:57 AM -05:00 from Erick de Oliveira Leal < 
>>erickdeoliveiral...@gmail.com >:
>> 
>>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 
> 
> 
 
--
 
 ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Fwd: maps/navigation data source

[ben . kimdi]

If maps compiled this way work well what's wrong with it?

Mit freundlichen Grüßen
Ben Kimdi

Am 03-Sep-2020 01:31:44 +0200 schrieb mnidqb9jz...@mail.ru:
> 
> OSM, is a fake map that is made by people 1000 of miles away from what they 
> are mapping based on
> 
> satellite images.
> 
> and no way to remove fake data.
> 
> On Wed, Sep 2, 2020 at 3:49 PM  wrote:

-
FreeMail powered by mail.de - MEHR SICHERHEIT, SERIOSITÄT UND KOMFORT

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

[OSM-talk] Fwd: [Maps-l] Public API for Wikimedia map tiles to be discontinued in 45 days

[Andy Mabbett]

Foarwarding for interest; of course WMF tiles use OSM data:


-- Forwarded message -
From: Erica Litrenta 
Date: Thu, 27 Aug 2020 at 18:33
Subject: [Maps-l] Public API for Wikimedia map tiles to be
discontinued in 45 days
To: 


 Today the Wikimedia Foundation is announcing the deprecation of the
public API for Wikimedia map tiles. Around mid October the Foundation
will end support for the Wikimedia Maps Service API [1]. This change
affects people using Wikimedia maps on their own website or app. Maps
on the Wikimedia sites, in Wikimedia-hosted tools and gadgets, and on
maps.wikimedia.org won't be affected.

This decision was made based on recent outage incidents, primarily due
to spikes in third party usage, along with an analysis showing that
more than a third of maps provided are to non-Wikimedia services
(including many to for-profit organizations).


After the most recent incident [2], the service was limited so that
only cached maps tiles would be available. While this protected the
servers, it made the service unpredictable and highlighted the
unsustainability of our tile service. So, we have made the decision to
discontinue the maps APIs for non-Wikimedia users.


This change will allow our teams working on Maps to focus on the
sustainability of the maps used within Wikimedia projects.


You can follow the implementation of this change on Phabricator [3].


Best,

Erica Litrenta

[1] https://maps.wikimedia.org/osm-intl/

[2] https://wikitech.wikimedia.org/wiki/Incident_documentation/20200204-maps

[3] https://phabricator.wikimedia.org/T261424

-- 
Erica Litrenta
Manager, Community Relations Specialists
https://meta.wikimedia.org/wiki/User:Elitre_(WMF)

___
Maps-l mailing list
map...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/maps-l


-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

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

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

[Clifford Snow]

As I read your proposal, it sounds like you have a solution but haven't
defined the problem. If you could focus on the problem and describe exactly
what is wrong with the current arrangement, and what will happen if we do
nothing, that might help. Otherwise I can not see the merits of your
proposal. From what I've read for the feedback you've received, you haven't
convinced anyone that there is a problem.

Best,
Clifford


-- 
@osm_washington
www.snowandsnow.us
OpenStreetMap: Maps with a human touch
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[Martin Koppenhoefer]

sent from a phone

> On 9. Aug 2020, at 21:16, john whelan  wrote:
> 
> And different features really are called difference things in different 
> countries.


+1, moreover, the „same“ features are different in different countries and 
cultures, and it is part of our work to define when we consider them still the 
same and where they start to be so different that another tag is required.

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

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

[Martin Koppenhoefer]

sent from a phone

> On 9. Aug 2020, at 21:04, pangoSE  wrote:
> 
> E.g. permanent unique ids, talk pages if we want that for every osmid, SPARQL 
> support, standardization benefits "riding the current ride in open data"


somehow you can have this already through the integration of wikidata: just add 
a wikidata reference to an object and you could decide to ignore all 
OpenStreetMap tags and rely only on wikidata (although it would not be 
advisable IMHO, looking at where wikidata is currently, you would loose lots of 
relevant information).

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

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

[Mateusz Konieczny via talk]

"riding the current ride in open data" - I am confused what is the meaning of 
that

"scripting support for botmakers" - as a bot operator and a bot author I am 
confused what is
supposed to be missing

"support for references and linking interactively to other data sources" - we 
have that,
see wikidata tag for example

"talk pages if we want that for every osmid" - changeset comments and notes
seem sufficient

"SPARQL support" - we have already some wikidata/OSM query engine and overpass 
turbo
And frankly Overpass is much nicer that SPARQL (this may be just me).

"Bots are very useful" - maybe, but it is 100% possible to have bots already so 
I am 
confused why it is mentioned

"possibility we don't have today regarding integration with e.g. wikidata." - 
given
what kind of ideas appear thanks to current wikidata integration (like 
deprecating name tag)
I prefer reducing wikidata integration rather than deepening it (or, the best 
solution - keep it as is)

Aug 9, 2020, 21:01 by pang...@riseup.net:

> Could you reply with your arguments in favor of the current one2one tag model 
> system in the other thread where I listed the benefits as I see them?
>
> E.g. permanent unique ids, talk pages if we want that for every osmid, SPARQL 
> support, standardization benefits "riding the current ride in open data", 
> scripting support for botmakers, and above all support for references and 
> linking interactively to other data sources.
> Bots are very useful e.g. to notify an editor of a possible tagging mistake 
> or checking urls of references. Martin could also reference an image in 
> Wikimedia commons directly on the statement it relates to.
>
> Unique Qids for every osm object that is decoupled from the underlying osmid 
> gives some possibility we don't have today regarding integration with e.g. 
> wikidata. 
>
> Cheers
>
> Mateusz Konieczny via talk  skrev: (9 augusti 2020 
> 20:14:03 CEST)
>
>> It still fails to provide even a single benefit over the current situation.
>>
>> Aug 9, 2020, 20:11 by pang...@riseup.net:
>>
>>>
>>>
>>>
>>>  Originalmeddelande 
>>> Från: pangoSE 
>>> Skickat: 9 augusti 2020 15:40:41 CEST
>>> Till: talk@openstreetmap.org
>>> Ämne: Re: [OSM-talk] Roadmap for deprecation of name tags in OSM
>>>
>>> This is another good reason to abandon this suggestion in favor of our own 
>>> wikibase instance.
>>>
>>> Philip Barnes  skrev: (9 augusti 2020 15:12:21 CEST)
>>> >On Sun, 2020-08-09 at 09:04 -0400, James wrote:
>>>
> Not to mention if someone wants to add a name for a new item/object,
> does the user need to create a wikidata item on top of it? Will the
> editor do it automatically? How does it pick the right one? Does it
> offer a list to the user? This is going to make osm a massive turn
> off to new contributors on the steep learning curve(which is already
> pretty high) to contributing to osm.
> This whole idea is really terrible and could just be offered as a
> post-processed data set: wikidata? use that instead of name tag.
>
>>> >This leads me to a fairly fundamental question, what if a mapper does
>>> >not want to be associated with wikidata and refuses to sign up?
>>> >Phil (trigpoint)
>>>
>>> -- 
>>> Skickat från min Android-enhet med k9.
>>>
>>> ___
>>> 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] Fwd: Re: Roadmap for deprecation of name tags in OSM

[john whelan]

I honestly can't see any benefit.  Splitting the data into two places adds
the danger of it getting out of sync.

Standard naming conventions would be nice but defining the standard name is
practically impossible.  Compare taginfo to the map features wiki page.
One problem with map features is what is written is often one person's idea
of what the standard name should be.

And different features really are called difference things in different
countries.  It can be difficult to stretch a "standard" name to cover many
things.

For example in Canada many highways have wide shoulders to dump snow on in
winter.  In summer they are often used by cyclists but they aren't cycle
lanes by any stretch of imagination even though some are paved.

Cheerio John

On Sun, Aug 9, 2020, 15:04 pangoSE  wrote:

> Could you reply with your arguments in favor of the current one2one tag
> model system in the other thread where I listed the benefits as I see them?
>
> E.g. permanent unique ids, talk pages if we want that for every osmid,
> SPARQL support, standardization benefits "riding the current ride in open
> data", scripting support for botmakers, and above all support for
> references and linking interactively to other data sources.
> Bots are very useful e.g. to notify an editor of a possible tagging
> mistake or checking urls of references. Martin could also reference an
> image in Wikimedia commons directly on the statement it relates to.
>
> Unique Qids for every osm object that is decoupled from the underlying
> osmid gives some possibility we don't have today regarding integration with
> e.g. wikidata.
>
> Cheers
>
> Mateusz Konieczny via talk  skrev: (9 augusti
> 2020 20:14:03 CEST)
>>
>> It still fails to provide even a single benefit over the current
>> situation.
>>
>> Aug 9, 2020, 20:11 by pang...@riseup.net:
>>
>>
>>
>>
>>  Originalmeddelande 
>> Från: pangoSE
>> Skickat: 9 augusti 2020 15:40:41 CEST
>> Till: talk@openstreetmap.org
>> Ämne: Re: [OSM-talk] Roadmap for deprecation of name tags in OSM
>>
>> This is another good reason to abandon this suggestion in favor of our
>> own wikibase instance.
>>
>> Philip Barnes  skrev: (9 augusti 2020 15:12:21
>> CEST)
>> >On Sun, 2020-08-09 at 09:04 -0400, James wrote:
>>
>> Not to mention if someone wants to add a name for a new item/object,
>> does the user need to create a wikidata item on top of it? Will the
>> editor do it automatically? How does it pick the right one? Does it
>> offer a list to the user? This is going to make osm a massive turn
>> off to new contributors on the steep learning curve(which is already
>> pretty high) to contributing to osm.
>> This whole idea is really terrible and could just be offered as a
>> post-processed data set: wikidata? use that instead of name tag.
>>
>> >This leads me to a fairly fundamental question, what if a mapper does
>> >not want to be associated with wikidata and refuses to sign up?
>> >Phil (trigpoint)
>>
>> --
>> Skickat från min Android-enhet med k9.
>>
>> ___
>> talk mailing list
>> talk@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk
>>
>>
>> ___
> 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] Fwd: Re: Roadmap for deprecation of name tags in OSM

[pangoSE]

Could you reply with your arguments in favor of the current one2one tag model 
system in the other thread where I listed the benefits as I see them?

E.g. permanent unique ids, talk pages if we want that for every osmid, SPARQL 
support, standardization benefits "riding the current ride in open data", 
scripting support for botmakers, and above all support for references and 
linking interactively to other data sources.
Bots are very useful e.g. to notify an editor of a possible tagging mistake or 
checking urls of references. Martin could also reference an image in Wikimedia 
commons directly on the statement it relates to.

Unique Qids for every osm object that is decoupled from the underlying osmid 
gives some possibility we don't have today regarding integration with e.g. 
wikidata. 

Cheers

Mateusz Konieczny via talk  skrev: (9 augusti 2020 
20:14:03 CEST)
>It still fails to provide even a single benefit over the current
>situation.
>
>Aug 9, 2020, 20:11 by pang...@riseup.net:
>
>>
>>
>>
>>  Originalmeddelande 
>> Från: pangoSE 
>> Skickat: 9 augusti 2020 15:40:41 CEST
>> Till: talk@openstreetmap.org
>> Ämne: Re: [OSM-talk] Roadmap for deprecation of name tags in OSM
>>
>> This is another good reason to abandon this suggestion in favor of
>our own wikibase instance.
>>
>> Philip Barnes  skrev: (9 augusti 2020 15:12:21
>CEST)
>> >On Sun, 2020-08-09 at 09:04 -0400, James wrote:
>>
 Not to mention if someone wants to add a name for a new
>item/object,
 does the user need to create a wikidata item on top of it? Will the
 editor do it automatically? How does it pick the right one? Does it
 offer a list to the user? This is going to make osm a massive turn
 off to new contributors on the steep learning curve(which is
>already
 pretty high) to contributing to osm.
 This whole idea is really terrible and could just be offered as a
 post-processed data set: wikidata? use that instead of name tag.

>> >This leads me to a fairly fundamental question, what if a mapper
>does
>> >not want to be associated with wikidata and refuses to sign up?
>> >Phil (trigpoint)
>>
>> -- 
>> Skickat från min Android-enhet med k9.
>>
>> ___
>> 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] Fwd: Re: Roadmap for deprecation of name tags in OSM

[Mateusz Konieczny via talk]

It still fails to provide even a single benefit over the current situation.

Aug 9, 2020, 20:11 by pang...@riseup.net:

>
>
>
>  Originalmeddelande 
> Från: pangoSE 
> Skickat: 9 augusti 2020 15:40:41 CEST
> Till: talk@openstreetmap.org
> Ämne: Re: [OSM-talk] Roadmap for deprecation of name tags in OSM
>
> This is another good reason to abandon this suggestion in favor of our own 
> wikibase instance.
>
> Philip Barnes  skrev: (9 augusti 2020 15:12:21 CEST)
> >On Sun, 2020-08-09 at 09:04 -0400, James wrote:
>
>>> Not to mention if someone wants to add a name for a new item/object,
>>> does the user need to create a wikidata item on top of it? Will the
>>> editor do it automatically? How does it pick the right one? Does it
>>> offer a list to the user? This is going to make osm a massive turn
>>> off to new contributors on the steep learning curve(which is already
>>> pretty high) to contributing to osm.
>>> This whole idea is really terrible and could just be offered as a
>>> post-processed data set: wikidata? use that instead of name tag.
>>>
> >This leads me to a fairly fundamental question, what if a mapper does
> >not want to be associated with wikidata and refuses to sign up?
> >Phil (trigpoint)
>
> -- 
> Skickat från min Android-enhet med k9.
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>

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

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

[pangoSE]

 Originalmeddelande 
Från: pangoSE 
Skickat: 9 augusti 2020 15:40:41 CEST
Till: talk@openstreetmap.org
Ämne: Re: [OSM-talk] Roadmap for deprecation of name tags in OSM

This is another good reason to abandon this suggestion in favor of our own 
wikibase instance.

Philip Barnes  skrev: (9 augusti 2020 15:12:21 CEST)
>On Sun, 2020-08-09 at 09:04 -0400, James wrote:
>> Not to mention if someone wants to add a name for a new item/object,
>> does the user need to create a wikidata item on top of it? Will the
>> editor do it automatically? How does it pick the right one? Does it
>> offer a list to the user? This is going to make osm a massive turn
>> off to new contributors on the steep learning curve(which is already
>> pretty high) to contributing to osm.
>> This whole idea is really terrible and could just be offered as a
>> post-processed data set: wikidata? use that instead of name tag.
>> 
>
>This leads me to a fairly fundamental question, what if a mapper does
>not want to be associated with wikidata and refuses to sign up?
>Phil (trigpoint)

-- 
Skickat från min Android-enhet med k9.

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

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

[pangoSE]

This was meant for the list.


 Originalmeddelande 
Från: pangoSE 
Skickat: 9 augusti 2020 11:09:08 CEST
Till: Mateusz Konieczny 
Ämne: Re: [OSM-talk] Roadmap for deprecation of name tags in OSM

Hi

Thanks for the response. 


Mateusz Konieczny via talk  skrev: (9 augusti 2020 
10:42:21 CEST)
>Aug 9, 2020, 10:25 by pang...@riseup.net:
>
>> I suggest we create a roadmap for deprecating of storing and updating
>names in OSM for objects with a Wikidata tag.
>>
>Absolutely no.
>
>tagging name tag is a fundamental  part of OSM tag,
>offloading it to a third party service is a mistake that will not
>happen

I disagree. Redundancy is a problem waiting to be solved.

>
>https://josm.openstreetmap.de/ticket/19655 contains several misleading,
>wrong, mistaken
>and problematic claims, statements and implications but I have no time
>to process in detail
>as the entire idea is fundamentally bad, mistaken, problematic, broken,
>not workable,
>not acceptable, not going to happen and wrong.

I disagree. The current handling of names in osm is redundant in many cases and 
badly broken when it comes to references.

>
>Some samples:
>
>"there is no such thing as an international name. Names are part of a
>language whih is part of a culture. They are not GIS objects and the 
>osm datamodel does not handle this complexity well at all."
>
>Are you aware that we have other tags beyond name tag?

Yes

>
>loc_name, name:pl and many others?

Yes. This is not a blocker. For loc_name and others a new wikidata property can 
be created.

>
>"No more name vandalism in osm. We export the name handling to
>wikidata which has a much better system for handling vandalism."
>
>Because vandalism in third-party service is superior?
>Are you seriously claiming that Wikidata has less trouble with
>vandalism
>and deals with it better?

Yes. The new york defacement could most probably have been avoided wih this 
approach. I have no statistics to back up this claim though.

If anyone have statistics I would love to read them.

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

[OSM-talk] Fwd: [Foundations] [DEADLINE: MAY 15] Apply for FOSS Responders Funding… NOW!

[Heather Leson]

Hi folks, I hope you and yours are safe and resting

Maybe for one of your open source projects


Heather

-- Forwarded message -
From: Alyssa Wright 
Date: Tue, 12 May 2020 at 02:11
Subject: [Foundations] [DEADLINE: MAY 15] Apply for FOSS Responders
Funding… NOW!
To: FLOSS Foundations 


Hi all,

Hope this note finds you well in light of current world events.

FOSS Responders  is a working group of
volunteers with a purpose to help those in the open source community
affected by the economic fallout from COVID19.

Along with Indeed, Open Source Collective, Google, GitHub, Linux Fund,
Sentry (and more) we will be hosting our very first Virtual FOSS Funding
Event
on
Friday, May 22nd.  And we want you!!

The event is a celebration of our community, our ingenuity, and our
resourcefulness during the best of times… and the worst of times. We’ll
have “rooms” set up to showcase selected projects and allocate $100K of
financial support.

*We encourage you to apply for that support
!
Deadline for Applications on May 15th. Act now! *

If you have any questions, feel free to ping me directly, email us at
he...@fossresponders.com and/or hop on the #fossresponders channel in the
opencollective  workspace.

They say we’re all on this together. Let’s make it so.

Best,
Alyssa.

PS Whether you have a request or just an itch to see your open source
friends (Because seriously, what does their curation of imaginary
background really look like? Can you believe that's in their library?), *ALL
are cordially invited to attend the FOSS Funding event. SIGN UP

NOW! While FREE AND OPEN SOURCE SUPPLIES last. *
___
foundations mailing list
foundati...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/foundations
-- 
Heather Leson
heatherle...@gmail.com
Twitter/skype: HeatherLeson
Blog: textontechs.com
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Fwd: trace and signs

[80hnhtv4agou--- via talk]

>As to a mapping rule, do we node, (the point symbol in ID edit)  put signs on 
>the map,
> 
>and under what authority do we not put signs on the map.
> 
>>Saturday, April 25, 2020 7:02 AM -05:00 from Warin < 61sundow...@gmail.com >:
>> 
>>On 25/4/20 8:35 pm, Oleksiy Muzalyev wrote:
>>> Here are some more examples demonstrating that signs could be of
>>> interest to travelers.
>>>
>>> - in this video the popular British travel video-blogger goes to great
>>> lengths to get to the specific sign to record his video:
>>>  https://youtu.be/6RQlQDp1uiU?t=90
>>>
>>> - it is customary during long distance cycling tours to take photos
>>> near the signs, as it would confirm the itinerary of the tour:
>>>
>>>  https://www.highlux.co.nz/category/cycle-touring/
>>>
>>> or
>>>
>>>  
>>> https://www.alamy.com/fully-packed-bicycle-long-distance-bike-parked-at-frontier-sign-chile-argentina-good-bye-argentina-image184906663.html
>>>
>>
>>Whilst tourist use signs to document their tour few of them are after a
>>particular sign and those usually from someone else's trip photos. If
>>they are after a particular sign then the location is probably gained
>>from the photo and/or document not from a map.
>>
>>There is a place that I know of that had a sign and it attracted
>>tourist. There were a few traffic accidents caused by these tourist
>>looking/stopping for this sign. The sign has been removed for safety. As
>>there is no sign there tourist do not slow or stop there any more, so
>>not more accidents. It is a 'place=location' in OSM terms but I am
>>loathed to map it for fear of recreating the problem.
>>
>>
>>___
>>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] Fwd: trace and signs

[Martin Koppenhoefer]

sent from a phone

> On 25. Apr 2020, at 14:03, Warin <61sundow...@gmail.com> wrote:
> 
> There is a place that I know of that had a sign and it attracted tourist.


there are many famous signs, but they are of course just a tiny fraction of all 
signs that are set up.

http://4.bp.blogspot.com/-hHKL0_Q2uUc/UEBbmbfM57I/BAc/_vpyx7R1r48/s1600/LAS+VEGAS+SIGN.jpg

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

Re: [OSM-talk] Fwd: trace and signs

[Warin]

On 25/4/20 8:35 pm, Oleksiy Muzalyev wrote:
Here are some more examples demonstrating that signs could be of 
interest to travelers.


- in this video the popular British travel video-blogger goes to great 
lengths to get to the specific sign to record his video: 
https://youtu.be/6RQlQDp1uiU?t=90


- it is customary during long distance cycling tours to take photos 
near the signs, as it would confirm the itinerary of the tour:


https://www.highlux.co.nz/category/cycle-touring/

or

https://www.alamy.com/fully-packed-bicycle-long-distance-bike-parked-at-frontier-sign-chile-argentina-good-bye-argentina-image184906663.html 




Whilst tourist use signs to document their tour few of them are after a 
particular sign and those usually from someone else's trip photos. If 
they are after a particular sign then the location is probably gained 
from the photo and/or document not from a map.


There is a place that I know of that had a sign and it attracted 
tourist. There were a few traffic accidents caused by these tourist 
looking/stopping for this sign. The sign has been removed for safety. As 
there is no sign there tourist do not slow or stop there any more, so 
not more accidents. It is a 'place=location' in OSM terms but I am 
loathed to map it for fear of recreating the problem.



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

Re: [OSM-talk] Fwd: trace and signs

[Oleksiy Muzalyev]

Here are some more examples demonstrating that signs could be of 
interest to travelers.


- in this video the popular British travel video-blogger goes to great 
lengths to get to the specific sign to record his video: 
https://youtu.be/6RQlQDp1uiU?t=90


- it is customary during long distance cycling tours to take photos near 
the signs, as it would confirm the itinerary of the tour:


https://www.highlux.co.nz/category/cycle-touring/

or

https://www.alamy.com/fully-packed-bicycle-long-distance-bike-parked-at-frontier-sign-chile-argentina-good-bye-argentina-image184906663.html

Best regards,

Oleksiy



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

Re: [OSM-talk] Fwd: trace and signs

[Oleksiy Muzalyev]

It is a very good question. I always search in a park the sign which 
bears its name. Some parks have such a sign and some don't.


It takes sometimes a lot of time to find the sign with the park's name. 
First of all, you do not know if it exists at all. So you have to walk 
several times around, looking at places where it might be.


For example I found this sign with the park's name: 
https://commons.wikimedia.org/wiki/Category:Centre_intercommunal_de_sports,_loisirs_et_nature_des_Evaux#/media/File:Centre-des-Evaux-3.jpg 

I took its photo and I used it in creating this Wikipedia article: 
https://fr.wikipedia.org/wiki/Centre_intercommunal_de_sports,_loisirs_et_nature_des_Evaux


It helps a lot if a discussion begins about the park's article. The 
image of the sign with the park's name is a good proof that it's the 
official park, and that its name reflected correctly on the map and in 
the article.


In this park I did not find the sign: 
https://fr.wikipedia.org/wiki/Parc_Baud-Bovy and the article, which I 
created, was almost removed by moderators. I had to prove park's 
existence via secondary sources.


So having a sign with the park's official name tagged and marked on the 
map, would save a lot of time while surveying a park. The park is 
usually quite large, it may have several entrances, and it is not 
possible to tell where the sign with the park's name could be, or if it 
exists at all.


Best regards,
Oleksiy


On 4/23/20 23:29, 80hnhtv4agou--- via talk wrote:
... how do you tag a sign ... park ...that is name of the place, place 
name.




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

Re: [OSM-talk] Fwd: trace and signs

[Warin]

On 24/4/20 7:29 am, 80hnhtv4agou--- via talk wrote:


 1. how do you close out the trace on the map after edit ?


I have no idea what this means. "Close out"?


 1. how do you tag a sign, mall, park, forest, that is name of the
place, place name.



If a mall, park, forest have a name then put the tag name=* on the feature.

Example:

leisure=park

name=Fred's Park


A sign that carries the name of a village, well I don't see any methods 
for tagging the sign itself.


The feature village can be mapped and carry the tag name=*, similar to 
any other feature.




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

[OSM-talk] Fwd: trace and signs

[80hnhtv4agou--- via talk]

*  how do you close out the trace on the map after edit ? 
*  how do you tag a sign, mall, park, forest, that is name of the place, place 
name.
 
 
   
--
 
 
 ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Fwd: Re[2]: Tag:manhole=telecom

[François Lacombe]

Given problem is you argue with pictures showing what is under the cap.
On the tag page picture - and on the ground - we can't say what is under
and if a man can't get down a ladder into a room.

I think all this stuff would require a formal proposal to discuss about
vocabulary and have opinions of several people.
We need standard definitions more than legal actually.

All the best

Le lun. 20 avr. 2020 à 01:02, <80hnhtv4a...@bk.ru> a écrit :

> I am trying to say the tag page is wrong,
> https://wiki.openstreetmap.org/wiki/Tag:manhole=telecom
> the picture is a fiber optics splice enclosure not a manhole
>
> https://www.multicominc.com/product/pencell-pem-2436-24x36x24-buried-cable-enclosure/
> https://www.thefoa.org/tech/ref/install/Microtrenching/Pages/25.html
> https://www.thefoa.org/tech/ref/appln/Prefab-underground.jpg
>
> this is a fiber splice manhole,
>
> https://www.jensenprecast.com/AT-T-Northern-California-a840/Telecom-Utility-Structures/Manholes-p14890/AT-T-4-x4-x4-fiber-optic-Intercept-Manhole-Page-1-of-2-d2315.pdf
>
> can we change the picture or put both on the same page with the legal
> industry names.
> https://www.lexico.com/en/definition/manhole
> ( a man goes into the hole) [manhole]
>
>
>
> Sunday, April 19, 2020 5:02 PM -05:00 from François Lacombe <
> fl.infosrese...@gmail.com>:
> To me, manhole applies in the two situations.
> We should make a distinction between the "cap" visible from the surface
> and the facility underground.
> Same shape of "cap" (I call it the manhole actually) can hide really
> different kind of stuff underground you won't be able to define without
> removing the cap.
> In OSM, most mappers will only be able to describe what is visible on
> surface. So this distinction would really be valuable.
> When I look for "cable manhole" in google, I see both pavement and road
> manholes.
> Then I found this :
> https://www.archiexpo.com/prod/dakota-group/product-150519-1693688.html
> The body below surface, buried underground would be called a "cable room".
> All the best
> François
>
> Le dim. 19 avr. 2020 à 23:14, 80hnhtv4agou--- via talk <
> talk@openstreetmap.org
> > a écrit :
>
>  this is an enclosure just put in the ground, level 3 fiber.
>
> https://s3-eu-west-1.amazonaws.com/mapillary.private.images/4KIBU1qe2CfjtcKtPHegeg/uploaded.jpg?AWSAccessKeyId=AKIAR47SN3BMII5SHG7V&Expires=1587328637&Signature=8%2FzNiW16zbU9FjWy0JD17cNwIns%3D
> https://www.thefoa.org/tech/ref/install/Microtrenching/Pages/25.html
>
> this is a manhole, ameritech, a t & t.
>
> https://s3-eu-west-1.amazonaws.com/mapillary.private.images/dSk9MhzCx0L0AAFzD-WqYQ/uploaded.jpg?AWSAccessKeyId=AKIAR47SN3BMII5SHG7V&Expires=1587329086&Signature=o%2F0CqAKQC1ltl0F2vCqXVIecRP4%3D
>
>
> https://www.jensenprecast.com/AT-T-Northern-California-a840/Telecom-Utility-Structures/Manholes-p14890/AT-T-4-x4-x4-fiber-optic-Intercept-Manhole-Page-1-of-2-d2315.pdf
>
>
> Sunday, April 19, 2020 3:06 PM -05:00 from Tom Pfeifer <
> t.pfei...@computer.org>:
> Dear 80hnhtv4agou,
> As OpenStreetMap is a worldwide project, we have to agree on a tagging
> scheme for an object that
> is worldwide comprehensible.
> We prefer to use the same tag for the same kind of thing.
> Thus we prefer not to introduce synonyms or regional variations.
> To make a feature be found more easily, "related terms" can be added in
> the wiki.
> In the particular case, some friendly colleague has already added ‹buried
> cable enclosure›
> to the manhole=telecom wiki page.
> Kind regards
> Tom
>
> On 19.04.2020 17:20, 80hnhtv4agou--- via talk wrote:
> > https://wiki.openstreetmap.org/wiki/Tag:manhole=telecom
> > in the united states this is not what it is called, so it was hard for
> me to find to use.
> > can the name be changed.
> >
> https://www.multicominc.com/product/pencell-pem-2436-24x36x24-buried-cable-enclosure/
> > to what it is ?
> ___
>
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Fwd: Re[2]: Tag:manhole=telecom

[80hnhtv4agou--- via talk]

I am trying to say the tag page is wrong,
https://wiki.openstreetmap.org/wiki/Tag:manhole=telecom
the picture is a fiber optics splice enclosure not a manhole
https://www.multicominc.com/product/pencell-pem-2436-24x36x24-buried-cable-enclosure/
https://www.thefoa.org/tech/ref/install/Microtrenching/Pages/25.html
https://www.thefoa.org/tech/ref/appln/Prefab-underground.jpg
 
this is a fiber splice manhole,
https://www.jensenprecast.com/AT-T-Northern-California-a840/Telecom-Utility-Structures/Manholes-p14890/AT-T-4-x4-x4-fiber-optic-Intercept-Manhole-Page-1-of-2-d2315.pdf
 
can we change the picture or put both on the same page with the legal industry 
names.
https://www.lexico.com/en/definition/manhole
( a man goes into the hole) [manhole] 
 
  
>Sunday, April 19, 2020 5:02 PM -05:00 from François Lacombe 
>:
>To me, manhole applies in the two situations.
>We should make a distinction between the "cap" visible from the surface and 
>the facility underground.
>Same shape of "cap" (I call it the manhole actually) can hide really different 
>kind of stuff underground you won't be able to define without removing the cap.
>In OSM, most mappers will only be able to describe what is visible on surface. 
>So this distinction would really be valuable.
>When I look for "cable manhole" in google, I see both pavement and road 
>manholes.
>Then I found this :  
>https://www.archiexpo.com/prod/dakota-group/product-150519-1693688.html
>The body below surface, buried underground would be called a "cable room".
>All the best
>François  
>Le dim. 19 avr. 2020 à 23:14, 80hnhtv4agou--- via talk < 
>talk@openstreetmap.org > a écrit :
>> this is an enclosure  just put in the ground, level 3 fiber.
>>https://s3-eu-west-1.amazonaws.com/mapillary.private.images/4KIBU1qe2CfjtcKtPHegeg/uploaded.jpg?AWSAccessKeyId=AKIAR47SN3BMII5SHG7V&Expires=1587328637&Signature=8%2FzNiW16zbU9FjWy0JD17cNwIns%3D
>>https://www.thefoa.org/tech/ref/install/Microtrenching/Pages/25.html
>> 
>>this is a manhole, ameritech, a t & t.
>>https://s3-eu-west-1.amazonaws.com/mapillary.private.images/dSk9MhzCx0L0AAFzD-WqYQ/uploaded.jpg?AWSAccessKeyId=AKIAR47SN3BMII5SHG7V&Expires=1587329086&Signature=o%2F0CqAKQC1ltl0F2vCqXVIecRP4%3D
>> 
>>https://www.jensenprecast.com/AT-T-Northern-California-a840/Telecom-Utility-Structures/Manholes-p14890/AT-T-4-x4-x4-fiber-optic-Intercept-Manhole-Page-1-of-2-d2315.pdf
>> 
>>>Sunday, April 19, 2020 3:06 PM -05:00 from Tom Pfeifer < 
>>>t.pfei...@computer.org >:
>>>Dear 80hnhtv4agou,
>>>As OpenStreetMap is a worldwide project, we have to agree on a tagging 
>>>scheme for an object that
>>>is worldwide comprehensible.
>>>We prefer to use the same tag for the same kind of thing.
>>>Thus we prefer not to introduce synonyms or regional variations.
>>>To make a feature be found more easily, "related terms" can be added in the 
>>>wiki.
>>>In the particular case, some friendly colleague has already added ‹buried 
>>>cable enclosure›
>>>to the manhole=telecom wiki page.
>>>Kind regards
>>>Tom
>>>
>>>On 19.04.2020 17:20, 80hnhtv4agou--- via talk wrote:
  https://wiki.openstreetmap.org/wiki/Tag:manhole=telecom
 in the united states this is not what it is called, so it was hard for me 
 to find to use.
 can the name be changed.
  
 https://www.multicominc.com/product/pencell-pem-2436-24x36x24-buried-cable-enclosure/
 to what it is ? __
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Fwd: Re[2]: Tag:manhole=telecom

[François Lacombe]

To me, manhole applies in the two situations.

We should make a distinction between the "cap" visible from the surface and
the facility underground.
Same shape of "cap" (I call it the manhole actually) can hide really
different kind of stuff underground you won't be able to define without
removing the cap.
In OSM, most mappers will only be able to describe what is visible on
surface. So this distinction would really be valuable.

When I look for "cable manhole" in google, I see both pavement and road
manholes.
Then I found this :
https://www.archiexpo.com/prod/dakota-group/product-150519-1693688.html

The body below surface, buried underground would be called a "cable room".

All the best

François

Le dim. 19 avr. 2020 à 23:14, 80hnhtv4agou--- via talk <
talk@openstreetmap.org> a écrit :

>  this is an enclosure just put in the ground, level 3 fiber.
>
> https://s3-eu-west-1.amazonaws.com/mapillary.private.images/4KIBU1qe2CfjtcKtPHegeg/uploaded.jpg?AWSAccessKeyId=AKIAR47SN3BMII5SHG7V&Expires=1587328637&Signature=8%2FzNiW16zbU9FjWy0JD17cNwIns%3D
> https://www.thefoa.org/tech/ref/install/Microtrenching/Pages/25.html
>
> this is a manhole, ameritech, a t & t.
>
> https://s3-eu-west-1.amazonaws.com/mapillary.private.images/dSk9MhzCx0L0AAFzD-WqYQ/uploaded.jpg?AWSAccessKeyId=AKIAR47SN3BMII5SHG7V&Expires=1587329086&Signature=o%2F0CqAKQC1ltl0F2vCqXVIecRP4%3D
>
>
> https://www.jensenprecast.com/AT-T-Northern-California-a840/Telecom-Utility-Structures/Manholes-p14890/AT-T-4-x4-x4-fiber-optic-Intercept-Manhole-Page-1-of-2-d2315.pdf
>
>
> Sunday, April 19, 2020 3:06 PM -05:00 from Tom Pfeifer <
> t.pfei...@computer.org>:
>
> Dear 80hnhtv4agou,
>
> As OpenStreetMap is a worldwide project, we have to agree on a tagging
> scheme for an object that
> is worldwide comprehensible.
>
> We prefer to use the same tag for the same kind of thing.
>
> Thus we prefer not to introduce synonyms or regional variations.
>
> To make a feature be found more easily, "related terms" can be added in
> the wiki.
>
> In the particular case, some friendly colleague has already added ‹buried
> cable enclosure›
> to the manhole=telecom wiki page.
>
> Kind regards
> Tom
>
> On 19.04.2020 17:20, 80hnhtv4agou--- via talk wrote:
> > https://wiki.openstreetmap.org/wiki/Tag:manhole=telecom
> >
> > in the united states this is not what it is called, so it was hard for
> me to find to use.
> >
> > can the name be changed.
> >
> >
> https://www.multicominc.com/product/pencell-pem-2436-24x36x24-buried-cable-enclosure/
> >
> > to what it is ?
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
>
>
>
>
>
>
> --
>
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Fwd: Re[2]: Tag:manhole=telecom

[80hnhtv4agou--- via talk]

 this is an enclosure  just put in the ground, level 3 fiber.
https://s3-eu-west-1.amazonaws.com/mapillary.private.images/4KIBU1qe2CfjtcKtPHegeg/uploaded.jpg?AWSAccessKeyId=AKIAR47SN3BMII5SHG7V&Expires=1587328637&Signature=8%2FzNiW16zbU9FjWy0JD17cNwIns%3D
https://www.thefoa.org/tech/ref/install/Microtrenching/Pages/25.html
 
this is a manhole, ameritech, a t & t.
https://s3-eu-west-1.amazonaws.com/mapillary.private.images/dSk9MhzCx0L0AAFzD-WqYQ/uploaded.jpg?AWSAccessKeyId=AKIAR47SN3BMII5SHG7V&Expires=1587329086&Signature=o%2F0CqAKQC1ltl0F2vCqXVIecRP4%3D
 
https://www.jensenprecast.com/AT-T-Northern-California-a840/Telecom-Utility-Structures/Manholes-p14890/AT-T-4-x4-x4-fiber-optic-Intercept-Manhole-Page-1-of-2-d2315.pdf
 
>Sunday, April 19, 2020 3:06 PM -05:00 from Tom Pfeifer < 
>t.pfei...@computer.org >:
> 
>Dear 80hnhtv4agou,
>
>As OpenStreetMap is a worldwide project, we have to agree on a tagging scheme 
>for an object that
>is worldwide comprehensible.
>
>We prefer to use the same tag for the same kind of thing.
>
>Thus we prefer not to introduce synonyms or regional variations.
>
>To make a feature be found more easily, "related terms" can be added in the 
>wiki.
>
>In the particular case, some friendly colleague has already added ‹buried 
>cable enclosure›
>to the manhole=telecom wiki page.
>
>Kind regards
>Tom
>
>On 19.04.2020 17:20, 80hnhtv4agou--- via talk wrote:
>>  https://wiki.openstreetmap.org/wiki/Tag:manhole=telecom
>>  
>> in the united states this is not what it is called, so it was hard for me to 
>> find to use.
>>  
>> can the name be changed.
>>  
>>  
>> https://www.multicominc.com/product/pencell-pem-2436-24x36x24-buried-cable-enclosure/
>>  
>> to what it is ?
>___
>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] Fwd: [Tagging] Tagging the local language

[Joseph Eisenberg]

> a change in the urban structure (urban confuguration, architectural style, 
> living standards, socially / ownerstructure, etc.). can mark a border very 
> strongly in some instances

Right, that's why we can map landuse=residential, landuse=industrial,
landuse=commercial and landuse=retail as areas with clear boundaries.

- Joseph Eisenberg

On 1/12/20, Martin Koppenhoefer  wrote:
> Am Sa., 11. Jan. 2020 um 01:30 Uhr schrieb Joseph Eisenberg <
> joseph.eisenb...@gmail.com>:
>
>> On Sat, Jan 11, 2020 at 2:49 AM Mateusz Konieczny
>> 
>> wrote:
>>
>>> or to use tricks like the “place=neighbourhood” one (which is based on
>>> POIs rather than polygons)?
>>>
>>> It is certainly wrong to do this.
>>>
>>
>> I think the “trick” here is referring to the stand at practice of mapping
>> all place= features as nodes, including neighborhoods, because their
>> boundaries are usually fuzzy (and precise boundaries can be mapped with
>> boundary=administrative or another boundary= tag).
>>
>
>
>
> mostly I agree, although it should be mentioned that neighbourhood (or
> other place boundaries like quarter and suburb) may be very clear although
> they aren't officially declared: when they are hard "natural" borders like
> railroads, rivers, motorways, etc. Also a change in the urban structure
> (urban confuguration, architectural style, living standards, socially /
> ownerstructure, etc.). can mark a border very strongly in some instances,
> without it having to be an administrative boundary.
>
> Cheers
> Martin
>

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

Re: [OSM-talk] Fwd: [Tagging] Tagging the local language

[Martin Koppenhoefer]

Am Sa., 11. Jan. 2020 um 01:30 Uhr schrieb Joseph Eisenberg <
joseph.eisenb...@gmail.com>:

> On Sat, Jan 11, 2020 at 2:49 AM Mateusz Konieczny 
> wrote:
>
>> or to use tricks like the “place=neighbourhood” one (which is based on
>> POIs rather than polygons)?
>>
>> It is certainly wrong to do this.
>>
>
> I think the “trick” here is referring to the stand at practice of mapping
> all place= features as nodes, including neighborhoods, because their
> boundaries are usually fuzzy (and precise boundaries can be mapped with
> boundary=administrative or another boundary= tag).
>



mostly I agree, although it should be mentioned that neighbourhood (or
other place boundaries like quarter and suburb) may be very clear although
they aren't officially declared: when they are hard "natural" borders like
railroads, rivers, motorways, etc. Also a change in the urban structure
(urban confuguration, architectural style, living standards, socially /
ownerstructure, etc.). can mark a border very strongly in some instances,
without it having to be an administrative boundary.

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

[OSM-talk] Fwd: [Tagging] Tagging the local language

[Joseph Eisenberg]

On Sat, Jan 11, 2020 at 2:49 AM Mateusz Konieczny 
wrote:

> or to use tricks like the “place=neighbourhood” one (which is based on
> POIs rather than polygons)?
>
> It is certainly wrong to do this.
>

I think the “trick” here is referring to the stand at practice of mapping
all place= features as nodes, including neighborhoods, because their
boundaries are usually fuzzy (and precise boundaries can be mapped with
boundary=administrative or another boundary= tag).

Oceans are better mapped as nodes because the cause no harm this way, and
database users can even use the node to find out the names in various
languages, and use them to put a label in a hand-selected place.

Mapping oceans (And seas) as multipolygons using the coastline would be
much worse, because the huge relations would be hard to maintain, the
borders between oceans would arbitrary and not verifiable, and editing the
coastline anywhere would be very likely to cause an editing conflict.

(These trains are also why it is a bad idea to map large bays, seas and
straits as areas)

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

[OSM-talk] Fwd: Re: bus stop

[80hnhtv4agou--- via talk]

Ok !
 
it is “hail and ride” but i am in the USA, we do not say it that way, as it 
say’s you put it on the way, road line
 
i have been using the point, and putting it on the side of the road.
 
but our signs have numbers on it.
 
the fields are wrong for our standards, and the only field that shows on 
the standard web edit map is name.

all i know to use is the ID edit.

From: Joseph Eisenberg
Sent: Friday, September 20, 2019 5:44 PM
To: OpenStreetMap talk mailing 
list
Subject: Re: [OSM-talk] bus stop
 
If a bus stop sign has a number, you can add this to the highway=bus_stop 
node with ref=*
 
BTW, I wouldn’t call “hail and ride” part of tyr public_transport proposal. 
As the link shows, it’s clearly a separate proposal. But it sounds sensible, 
and 
I agree that if a route has no fixed stops it makes sense to just create a 
route 
relation and only add the first and last stop as highway=bus_stop.
 
That’s what works here in Indonesia, where most local buses will pick up or 
drop off passengers anywhere along the route.
 
Joseph
 
On Sat, Sep 21, 2019 at 3:14 AM Johnparis 
< ok...@johnfreed.com > wrote:
>If the bus route does not have fixed stops, it is a hail-and-ride route, 
>  not a fixed-stop route. Public Transport v2 takes both possibilities into 
>  account.
> 
>The route relation should include all the road segments involved, and the 
>  relevant segments should have the role:
>hail_and_ride
> 
>See  https://wiki.openstreetmap.org/wiki/Proposed_features/hail_and_ride
> 
>As to the name vs number, the agreed naming convention is pretty clearly 
>  spelled out in PTv2. Usually something like this:
> 
>For the route master ... Bus 2: City Hall <-> Library (or you can 
>  use <=> or ↔) 
>For one variant ... Bus 2: City Hall -> Library (or you can use => 
>  or →)
>For another variant ... Bus 2: Library -> City Hall
> 
>etc.
> 
>I have ridden buses in many US cities (although never a hail-and-ride) 
>  and they fit nicely into this format.
> 
>The line number itself goes in the ref tag in the route 
>  relation.
> 
> 
> 
> 
> 
>On Fri, Sep 20, 2019 at 5:03 PM john whelan 
>  < jwhelan0...@gmail.com > wrote:
>>I'm not sure this is quite the place for this discussion but Europe 
>>also has some bus routes that pick up and drop off on request.  Just 
>>don't map none existent stops. 
>> 
>>Ottawa Canada has fixed stops as do many other locations in North 
>>America.
>> 
>>I suggest you try to map following the wiki map features.  If 
>>someone is changing your tags then discuss the matter with them as is the 
>>traditional way to resolve the problem.
>> 
>>Cheerio John
>> 
>>On Fri, Sep 20, 2019, 10:46 AM 80hnhtv4agou--- 
>>via talk, < talk@openstreetmap.org > 
>>wrote:
>>>europe vs. united states,
>>> 
>>>https://wiki.openstreetmap.org/wiki/Tag:public_transport%3Dplatform
>>> 
>>>1. does not match the way we catch the bus in the usa and the fields 
>>>  are to strict.
>>> 
>>>2. is a place where i will stand to catch the bus, sign or no sign 
>>>  etc.
>>> 
>>>3. the map point reflects the area and stops are not set in stone but 
>>>  is based on a driver etc.
>>> 
>>>4. bus stops are numbered routes as on the sign, the fields do not 
>>>  reflect or allow for this, just the name,
>>> 
>>>the standard web edit map reflects points not route lines, google 
>>>  puts in a no. not a line.
>>> 
>>>looking at a map numbers are more important than names and not all 
>>>  stops have names like
>>> 
>>>someone's driveway.
>>> 
>>>  ___

--


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

[OSM-talk] Fwd: Feature Proposal - Voting - Mapping disputed boundaries

[Johnparis]

As promised, I have opened the Mapping Disputed Boundaries proposal for
voting. Voting will be open until Feb. 10.

https://wiki.openstreetmap.org/wiki/Proposed_features/Mapping_disputed_boundaries#Voting

The main discussion has been on the Tagging list: 

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

[OSM-talk] Fwd: [Talk-asia] Grab’s GlobalLogic OSM team edits in Thailand

[Mishari Muqbil]

Hi All,

Thank you everyone for your emails and comments so far both on and off list.

Here is more information for your consideration prepared by @GOwin and some
mappers from Talk-Asia

https://lists.openstreetmap.org/pipermail/talk-asia/2019-January/15.html


Best regards
Mishari


-- Forwarded message -
From: Erwin Olario 
Date: Tue, Jan 15, 2019, 15:11
Subject: [Talk-asia] Grab’s GlobalLogic OSM team edits in Thailand
To: 


The original document (in original formatting) from which the following
text was copied is at: https://hackmd.io/s/HkZmHZ5z4

The following summary is a synthesis of the individual assessments made by
the volunteer mappers. I am responsible for any errors you may find in this
document. The invidual assessments are available through their respective
links.

We are sharing these findings with the rest of the Asian OSM communities
with the hope of promoting open discussions, and constructive engagement
for all parties. We feel that many other (Asian) communities can  benefit
from the exchange.

Kind regards,
Erwin

P.S.
Link to Supaplex's review notes are unavailable as of this writing.

---

Grab operates in Southeast Asia, and their OpenStreetMap editing
operations are contracted to Global Logic. They have conducted editing
in several other countries in south-east Asia prior to their foray in
Thailand. These never came un-noticed by locals and didnt’t always have
a great start [0], but in time, developed into positive working relationship
with these communities.

In December 2018, an article was published in TechCrunch [1] that described
the edits made by Grab’s contractor, Global Logic, as “absolute
disaster.” This tickled the interest of some mappers from several Asian
communities, and they agreed to conduct their own assessments of said
edits in Thailand.


Changeset assessments by volunteers

The following volunteers agreed to conduct their own indpendent
assessments of the changesets made by acknowledged team members [2] of Grab
Logic. These volunteers have extensive experience in OpenStreetMap, and
are known to be active OSM advocates within their respective
communities.

Reviewer OSM username Assessments
 -- -
ABROKWA, Kelvin Muzirian [4] Notes [5]
CHEN, DennisChen Supaplex[6] Notes [7]
DWIJANANTO, Adityo Adityo[8] Notes [9]
OLARIO, Erwin GOwin[10] Notes[11]
SAMBALE, Maning Maning[12] Notes[13]

The instruction to volunteers was to randomly select changesets using an
OsmCha filter [3] of un-reviewed changeseets of Grab’s Global Logic team in
Thailand, numbering about 7,000 edits. And to use OsmCha to verify said
changesets, and leave comments on them to record observations, if
necessary.


Conclusion

As with any other countries with active mapping volunteers, the Thai
mapping community is similarly lucky to have their very own active,
diligent, and prolific mappers who make time to map their favorite
neighbourhoods. We’ve frequently seen usernames which became familar
after several changeset validation, and we kept seeing the same names
again and again. Kudos to these contributors.

Overall, there is no substantive evidence to support the allegation of
massive detrimental edits, or systematic errors by Grab’s Global Logic
OpenStreetMap editing team. The errors found appear to be isolated, and
though there were unusual edits (that aren’t necessarily bad), there are
some bad edits that should have been caught by their internal Quality
Assurance (QA) team - the onus of primary validation of their team edits
should not be on the OSM community, but Grab’s Global Logic editing
team.

A few changesets were marked as bad, but none were considered critical.
Those marked as bad should be immediately addressed by Grab’s OSM team.

Some unusual behaviors were noticed:
* deleting road segments and
re-adding them;
* redundantly adding oneway=yes to roundabouts;
* their JOSM settings appear some users use a different/edited source
strings
for the same imagery, instead of what’s available by default from JOSM.

These are unusual, but nothing major or critical.

There are instances of inconsistencies with imagery interpretation:
tagging, use of various imagery and adjusting for offsets. The mappers’
training and on-boarding process can improve in these areas, and all
other mappers, ideally could have re-orientation to familiarize
themselves with the issues raised.

The Grab’s OSM team should look into supplementing their imagery source
with Mapillary/OpenStreetCam imagery collected by the local community.
They’ve been helpful to the validators in many instances during this
validation effort. Their QA team should take advantage of those, as
well.

This is not to say that the complaints from the local community are
unsound - local knowledge trumps imagery interpretation - feedback from
the community should always be considered, and investigated closer.
Remote mapping, validation and on-the-ground validation play an
important role 

Re: [OSM-talk] Fwd: DWG policy on Crimea

[Warin]

On 23/10/18 03:24, Mateusz Konieczny wrote:
22. Oct 2018 16:59 by colin.sm...@xs4all.nl 
:


On 2018-10-22 16:34, Mateusz Konieczny wrote:

I strongly disagree, we map reality.

There is no one true reality, only perceptions.


There is both a true reality and our biased interpretation of it. But 
it many


cases it is possible to select criteria, rules, categorizations where 
bias is small and


our interpretation align.


But anyway that is a philosophical claim and that discussion is 
unlikely to lead anything useful.



Which reality takes precedence in your mind, may not be the same
for everyone. Reality is subjective.

What is the test to apply to decide whether a point is included in
country A or country B?


In case of Russian/Ukrainian border, as defined by on the ground line 
of control


"is area controlled by Russian army or Ukrainian army" works quite 
well, better than


"is this area claimed by Russia" or "is this area claimed by Ukraine"


In the case of disputed borders, there are at least two realities
(as perceived by the parties to the dispute) and possibly a third
reality as perceived by a number of locals


There is one reality and multiple interpretations of it. It is 
preferable to map things so that


interpretations are not different between mappers.




Some interesting reading here on the 'reality' of a 'country'..
https://www.abc.net.au/news/2018-11-03/countries-changing-what-it-means-to-be-a-nation-state/10435028

In particular the Mohawk Nation at Akwesasne is of interest - spans 2 
'countries' ... I think it is like the reindeer headers of Finland/Russia.
Think you'll find the perceptions change depending on the experience of 
the individual and possibly their cultural links.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Fwd: Short ways added to substitute barriers

[Martin Koppenhoefer]

sent from a phone

> On 29. Oct 2018, at 11:11, Mateusz Konieczny  wrote:
> 
> I would consider it as a tagging for renderer, and it would be preferable to 
> avoid it (tagging
> 
> access on gate should be sufficient). On the other hand it is one of the 
> least harmful ones
> 


It should be discouraged, if there is a restriction through the gate, it should 
go on the gate, not on the way passing through. The result may come close to 
the actual situation but it is still wrong.


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

Re: [OSM-talk] Fwd: Short ways added to substitute barriers

[Mateusz Konieczny]

29. Oct 2018 11:43 by davefoxfa...@btinternet.com 
:

>  It's the gate which is the restriction. The problem is the gate
> doesn't have any subtags to indicate access.
>




I am using access=*, vehicle=*, bicycle=*, foot=*, opening_hours=* 




At least for gates in my region it is sufficient.

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

Re: [OSM-talk] Fwd: Short ways added to substitute barriers

[Dave F]

Hi

I've had similar in my area, also by Amazon Logistics *, where they 
added a short section around a gate like one you've indicated with 
access=private. I removed it as you can drive right up to the gate. This 
is tagging incorrectly for the router.


 It's the gate which is the restriction. The problem is the gate 
doesn't have any subtags to indicate access. It could be permanently 
open or locked shut. It might have a latch operable by all or a keypad 
entry allowing entry to specific people. etc.



* Personally, I think causing more harm than benefit, but that's for 
another thread.


Cheers
DaveF

On 29/10/2018 03:08, Jem wrote:


Re: https://www.openstreetmap.org/way/634085262 and several more like 
it in the area.


It seems that new, short ways have been introduced to replicate the 
purpose of the existing barrier nodes. i.e. to prevent routing for 
vehicular traffic. I believe it is incorrect and just adds complexity.


I plan to contact the user to discuss, but want to make sure I'm 
right. Can any experienced members please advise?



___
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] Fwd: Short ways added to substitute barriers

[Jem]

Your assumptions are spot-on. Thanks for the advice.

On Mon, 29 Oct 2018 at 20:12, Mateusz Konieczny 
wrote:

> 29. Oct 2018 04:08 by jem.maw...@gmail.com:
>
>
> Re: https://www.openstreetmap.org/way/634085262 and several more like it
> in the area.
>
> It seems that new, short ways have been introduced to replicate the
> purpose of the existing barrier nodes. i.e. to prevent routing for
> vehicular traffic. I believe it is incorrect and just adds complexity.
>
> I plan to contact the user to discuss, but want to make sure I'm right.
> Can any experienced members please advise?
>
>
> I am assuming that there is a gate here and there is no short segment
> where
>
> motor vehicles are forbidden - though weirder thing happened and maybe
> there is a sign
>
> meters before gate from each side "motor vehicles forbidden".
>
>
> I would consider it as a tagging for renderer, and it would be preferable
> to avoid it (tagging
>
> access on gate should be sufficient). On the other hand it is one of the
> least harmful ones
>
> so I would it phrase it "it is not necessary to do that" rather "it is
> harmful, stop immediately,
>
> I reverted your edits".
>
> ___
> 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] Fwd: Short ways added to substitute barriers

[Mateusz Konieczny]

29. Oct 2018 04:08 by jem.maw...@gmail.com :


>
> Re: > https://www.openstreetmap.org/way/634085262 
> >  and several more like it in 
> the area.
> It seems that new, short ways have been introduced to replicate the purpose 
> of the existing barrier nodes. i.e. to prevent routing for vehicular traffic. 
> I believe it is incorrect and just adds complexity.
> I plan to contact the user to discuss, but want to make sure I'm right. Can 
> any experienced members please advise?




I am assuming that there is a gate here and there is no short segment where 


motor vehicles are forbidden - though weirder thing happened and maybe there is 
a sign 


meters before gate from each side "motor vehicles forbidden".





I would consider it as a tagging for renderer, and it would be preferable to 
avoid it (tagging

access on gate should be sufficient). On the other hand it is one of the least 
harmful ones

so I would it phrase it "it is not necessary to do that" rather "it is harmful, 
stop immediately,

I reverted your edits".


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

[OSM-talk] Fwd: Short ways added to substitute barriers

[Jem]

Re: https://www.openstreetmap.org/way/634085262 and several more like it in
the area.

It seems that new, short ways have been introduced to replicate the purpose
of the existing barrier nodes. i.e. to prevent routing for vehicular
traffic. I believe it is incorrect and just adds complexity.

I plan to contact the user to discuss, but want to make sure I'm right. Can
any experienced members please advise?
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Fwd: DWG policy on Crimea

[Martin Koppenhoefer]

sent from a phone

> On 23. Oct 2018, at 11:06, Christoph Hormann  wrote:
> 
> I think that would not be verifiable.  Different political fractions 
> often even have different opinions on the extent of their country.  OSM 
> is not a place to record a spectrum of opinions on political goals and 
> human beliefs, it is meant to record a single consistent model of the 
> verifiably observable nature of reality.


just because not all alternative borders are verifiable does not mean none of 
them is. When someone claims former borders we can rely on the osm versions of 
them. There will be rules, you could not claim any border, but if there are 
significant, alternative, documented views (according to criteria which will 
have to be established), you could add them.

A single consistent model of reality does not exclude the mapping of different 
claims for the same territory, rather the opposite it can be seen as a 
requirement for the faithful representation of the reality in certain areas to 
be able to map these claims.

Cheers, Martin 





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

Re: [OSM-talk] Fwd: DWG policy on Crimea

[Johnparis]

This thread has strayed rather far afield from the original question, which
was whether the OSM depiction of Crimea corresponds to the OSMF policy. It
seems clear to me that it does not.

I would suggest that the depiction of Northern Cyprus does not correspond
to the policy either. The actual physical control boundary is depicted at
admin_level 3 or 4 rather than 2.

Cheers,

John

On Tue, Oct 23, 2018 at 1:05 PM Frederik Ramm  wrote:

> Hi,
>
> On 23.10.2018 11:06, Christoph Hormann wrote:
> > I think that would not be verifiable.  Different political fractions
> > often even have different opinions on the extent of their country.  OSM
> > is not a place to record a spectrum of opinions
>
> Agreed. I would be tempted to say, however, that if a country requires a
> certain boundary depiction by law, like e.g. India and China do, then
> that's the same level of verifiability like that country's internal
> boundaries for which we also rely on what the "official" take is. At
> least the current laws regarding the Indian border are much more than
> "an opinion of a political faction".
>
> Having said that - Portugal still officially claims Olivença but it
> seems to be more a folkloristic thing than an actual dispute, and the
> average Portuguese would probably be astonished if a map were to
> actually depict Olivença as part of Portgual. This means we'd have to
> start which claims are serious and which are just for old times' sake ;)
>
> Bye
> Frederik
>
> --
> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
>
> ___
> 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] Fwd: DWG policy on Crimea

[Greg Troxel]

Paul Johnson  writes:

> Not to mention that the situation of a country claiming territory that it
> physically controls, but only it recognizes, is also a relatively rare
> thing this decade.  Playing it conservatively in the "Russia claims Crimea
> and controls it, but unilaterally and by force from Ukraine" is definitely
> a situation that deserves both claims being mapped until the broader
> international community does.  I believe the original complaint to be
> generously asking a lot given the context of this specific dispute and
> they're arguing a side one country says "yes", and literally every other
> country or very close close to it) says "no".  Would be like if the US
> arbitrarily steamed into the Manitoba and claimed it as a state...pretty
> sure the world would see both claims and at least have serious problems
> with one until the locals settled it definitively and, as the world views
> it, either amicably or definitively but preferably both.  Given that Hans
> Island isn't a settled issue between Canada and Denmark with literally zero
> people and only speculative resources at stake, 30 years later, don't count
> on Crimea getting resolved any faster given the current pace to resolve it
> on the ground.

You make very good points and I don't disagree with them.

I was trying to avoid getting into the details, and only trying to rebut
the notion that "we accept government data abouto boundaries, so we
should accept it here too".   This is actually consistent with what you
said, that if multiple adjoining governments have the same idea of the
boundary, that's a clue that it's uncontested and probably good data.




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

Re: [OSM-talk] Fwd: DWG policy on Crimea

[Christoph Hormann]

On Tuesday 23 October 2018, Frederik Ramm wrote:
>
> Agreed. I would be tempted to say, however, that if a country
> requires a certain boundary depiction by law, like e.g. India and
> China do, then that's the same level of verifiability like that
> country's internal boundaries for which we also rely on what the
> "official" take is. At least the current laws regarding the Indian
> border are much more than "an opinion of a political faction".

A territorial claim that does not represent de facto administration is 
usually inherently non-verifiable because the claiming authority is by 
definition the only source of the information (this is why it is called 
a claim).

Unless a territorial claim coicides with a de facto administrative 
division its geometry is usually not independently verifiable.  India 
would certainly remove any boundary markers indicating the limits of a 
Chinese claim on territory they control.

Boundaries of de facto administration OTOH can normally be independently 
verified even at the higher admin levels if they are demarcated or if 
they coicide with physically observable features.  The fact that much 
of the administrative boundary data in OSM is imported and never has 
actually been verified on the ground is a different matter.

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

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

Re: [OSM-talk] Fwd: DWG policy on Crimea

[Frederik Ramm]

Hi,

On 23.10.2018 11:06, Christoph Hormann wrote:
> I think that would not be verifiable.  Different political fractions 
> often even have different opinions on the extent of their country.  OSM 
> is not a place to record a spectrum of opinions 

Agreed. I would be tempted to say, however, that if a country requires a
certain boundary depiction by law, like e.g. India and China do, then
that's the same level of verifiability like that country's internal
boundaries for which we also rely on what the "official" take is. At
least the current laws regarding the Indian border are much more than
"an opinion of a political faction".

Having said that - Portugal still officially claims Olivença but it
seems to be more a folkloristic thing than an actual dispute, and the
average Portuguese would probably be astonished if a map were to
actually depict Olivença as part of Portgual. This means we'd have to
start which claims are serious and which are just for old times' sake ;)

Bye
Frederik

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

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

Re: [OSM-talk] Fwd: DWG policy on Crimea

[Mateusz Konieczny]

23. Oct 2018 08:57 by frede...@remote.org :


> It would however be interesting to develop a tagging scheme that lets us
> not only record "this border is disputed" but also "this is the extent
> of country X according to country Y", which we currently don't have.
>




It seems close to ratings, reviews and other things that should not be  

kept in OSM database.

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

Re: [OSM-talk] Fwd: DWG policy on Crimea

[Christoph Hormann]

On Tuesday 23 October 2018, Frederik Ramm wrote:
>
> It would however be interesting to develop a tagging scheme that lets
> us not only record "this border is disputed" but also "this is the
> extent of country X according to country Y", which we currently don't
> have.

I think that would not be verifiable.  Different political fractions 
often even have different opinions on the extent of their country.  OSM 
is not a place to record a spectrum of opinions on political goals and 
human beliefs, it is meant to record a single consistent model of the 
verifiably observable nature of reality.

If data users need additional data for their purposes they need to 
obtain it from other sources.

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

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

Re: [OSM-talk] Fwd: DWG policy on Crimea

[Frederik Ramm]

Hi,

the Crimea issue is currently being discussed in DWG.

Regarding the wider question of boundaries, here is our policy on
disputed boundaries

https://wiki.osmfoundation.org/w/images/d/d8/DisputedTerritoriesInformation.pdf

This policy is not likely to change any time soon.

It would however be interesting to develop a tagging scheme that lets us
not only record "this border is disputed" but also "this is the extent
of country X according to country Y", which we currently don't have.

Bye
Frederik

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

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

Re: [OSM-talk] Fwd: DWG policy on Crimea

[Paul Johnson]

On Mon, Oct 22, 2018 at 7:29 PM Greg Troxel  wrote:

> Yuri Astrakhan  writes:
>
> > On Mon, Oct 22, 2018 at 8:22 AM Mateusz Konieczny <
> matkoni...@tutanota.com>
> > wrote:
> >
> >> I think a country relation should describe how the specific country
> think
> >> of its borders. So if two countries claim the same territory, those two
> >> relations will overlap.
> >>
> >> That is absurd and conflict with OSM rule to map what exists.
> >>
> > On the contrary, it actually matches OSM rules better than deciding
> > yourself.  When drawing a city outline, you go to that city's government,
> > and get the geoshape from them. By extension, if you draw a country, you
> > should use that country's definition.  If two country's definitions
> happen
> > to overlap, we ought to document both.
>
> Yes, we use government data to draw boundaries sometimes.  When there
> are no disputes, and the boundaries from many sources all line up, and
> mappers can see on the ground the markers and signs and it's all
> consistent, this is perfectly fine.
>
> The situation of a country claiming territory that is does not
> physically control is entirely different.
>

Not to mention that the situation of a country claiming territory that it
physically controls, but only it recognizes, is also a relatively rare
thing this decade.  Playing it conservatively in the "Russia claims Crimea
and controls it, but unilaterally and by force from Ukraine" is definitely
a situation that deserves both claims being mapped until the broader
international community does.  I believe the original complaint to be
generously asking a lot given the context of this specific dispute and
they're arguing a side one country says "yes", and literally every other
country or very close close to it) says "no".  Would be like if the US
arbitrarily steamed into the Manitoba and claimed it as a state...pretty
sure the world would see both claims and at least have serious problems
with one until the locals settled it definitively and, as the world views
it, either amicably or definitively but preferably both.  Given that Hans
Island isn't a settled issue between Canada and Denmark with literally zero
people and only speculative resources at stake, 30 years later, don't count
on Crimea getting resolved any faster given the current pace to resolve it
on the ground.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Fwd: DWG policy on Crimea

[Greg Troxel]

Yuri Astrakhan  writes:

> On Mon, Oct 22, 2018 at 8:22 AM Mateusz Konieczny 
> wrote:
>
>> I think a country relation should describe how the specific country think
>> of its borders. So if two countries claim the same territory, those two
>> relations will overlap.
>>
>> That is absurd and conflict with OSM rule to map what exists.
>>
> On the contrary, it actually matches OSM rules better than deciding
> yourself.  When drawing a city outline, you go to that city's government,
> and get the geoshape from them. By extension, if you draw a country, you
> should use that country's definition.  If two country's definitions happen
> to overlap, we ought to document both.

Yes, we use government data to draw boundaries sometimes.  When there
are no disputes, and the boundaries from many sources all line up, and
mappers can see on the ground the markers and signs and it's all
consistent, this is perfectly fine.

The situation of a country claiming territory that is does not
physically control is entirely different.

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

Re: [OSM-talk] Fwd: DWG policy on Crimea

[Oleksiy Muzalyev]

The situation with Crimea is not clear-cut. It is kind of complicated. 
For instance, the climate in Crimea is very dry, that is why the water 
from the river Dnieper had been transferred to Crimea by an immense 
artificial North Crimean Canal [1]. Now the Dnieper water is not sold to 
Crimea any more.


The newspaper Le Monde named Rana Dasgupta one of 70 people who are 
making the world of tomorrow [2]. Speaking figuratively, an electrician 
may work with wires without knowing Maxwell's equations or Ohm's law 
formulas. Still, it is better that he has some notion of the theory of 
electromagnetism.


The same is here. We try to discuss border dispute between the nation 
states. I just recommended to read an article [3] of the well known 
essayist and thinker about the nation state evolution as a political, 
economical, and philosophical concept. It will not solve this dispute, 
but at least, its nature could be better understood.


[1] https://en.wikipedia.org/wiki/North_Crimean_Canal
[2] https://en.wikipedia.org/wiki/Rana_Dasgupta
[3] 
https://www.theguardian.com/news/2018/apr/05/demise-of-the-nation-state-rana-dasgupta


Best regards,
Oleksiy

On 22.10.18 15:25, Mateusz Konieczny wrote:
Can you summarize parts of this article (5k+ words, in "long read" 
section) that are relevant to

tagging of Russian and Ukrainian border in the Crimea?

22. Oct 2018 00:44 by oleksiy.muzal...@bluewin.ch 
:


Hi Martin,

Before continuing this discussion further, I would advise to read
the amazing article "The demise of the nation state" by Rana
Dasgupta available via this link:

https://www.theguardian.com/news/2018/apr/05/demise-of-the-nation-state-rana-dasgupta

The issue of national state boundaries is more profound and
ubiquitous than it may seem at first sight. This topic is
controversial and complicated, and Rana Dasgupta's analyses
provides some good starting-point insights.

Best regards,
Oleksiy

On 21.10.18 16:12, Martin Koppenhoefer wrote:

Dear all,

we all know how sensible the topic of disputed boundaries can
be (they are not necessarily a big problem, many boundary
disputes like between Italy and France about the summit of
Mont Blanc / Monte Bianco, have little bearing on the actual
life of people).

Therefore we can all be satisfied there is clear guidance from
the board how to deal with this: the local situation
determines how we map, and the OSMF is explicit here:
“National borders are particularly sensitive. Currently, we
record one set that, in OpenStreetMap contributor opinion, is
most widely internationally recognised and best meets
realities on the ground, generally meaning physical control.”


https://wiki.osmfoundation.org/w/images/d/d8/DisputedTerritoriesInformation.

pdf


When I recently looked at Crimea I noticed it is still part of
the Ucraine in OSM: https://www.openstreetmap.org/relation/60199

As many might know, the current boundary situation for Crimea
was frozen 4 years ago “for a short time” by the DWG and so I
asked them about their current position 2 months ago, and
after I got no reply, tried to remind them 5 weeks ago, but
have not yet gotten any reply, so I am now opening this thread
here.

IMHO, for consistency and credibility, we should either
recognize that Russia is actually controlling Crimea, or we
should update the disputed borders information. As I believe
the general concept of ground truth for admin boundaries was a
good idea, I would tend to the former.

I also believe the actual situation has already been ignored
for too long. When the thing is still dynamic or/and we’re in
the middle of a conflict it can be wise to step back and see
for some time how things are evolving, but 4 years are a lot
of time, something like one year would seem more reasonable.

What do you think?

Cheers, Martin

sent from a phone

Begin forwarded message:

*From:* Martin Koppenhoefer mailto:dieterdre...@gmail.com>>
*Date:* 20. August 2018 at 10:42:33 CEST
*To:* d...@osmfoundation.org 
*Subject:* *DWG policy on Crimea*


Dear members of the DWG,

as of this question in the help forum:


https://help.openstreetmap.org/questions/65436/what-is-the-current-position-of-the-dataworkinggroup-on-crimea


I kindly invite you to reconsider and eventually update
your position on the situation in Crimea.

As you have stated in 2014, this should not be the long
term way to deal with the si

Re: [OSM-talk] Fwd: DWG policy on Crimea

[Mateusz Konieczny]

22. Oct 2018 16:59 by colin.sm...@xs4all.nl :


>
> On 2018-10-22 16:34, Mateusz Konieczny wrote:
>
>>
>> I strongly disagree, we map reality.
>>
>
> There is no one true reality, only perceptions. 
>




There is both a true reality and our biased interpretation of it. But it many

cases it is possible to select criteria, rules, categorizations where bias is 
small and

our interpretation align.




But anyway that is a philosophical claim and that discussion is unlikely to 
lead anything useful.

  


>
> Which reality takes precedence in your mind, may not be the same for 
> everyone. Reality is subjective.
>
> What is the test to apply to decide whether a point is included in country A 
> or country B?
>




In case of Russian/Ukrainian border, as defined by on the ground line of 
control 


"is area controlled by Russian army or Ukrainian army" works quite well, better 
than 


"is this area claimed by Russia" or "is this area claimed by Ukraine"



>
> In the case of disputed borders, there are at least two realities (as 
> perceived by the parties to the dispute) and possibly a third reality as 
> perceived by a number of locals
>




There is one reality and multiple interpretations of it. It is preferable to 
map things so that

interpretations are not different between mappers.

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

Re: [OSM-talk] Fwd: DWG policy on Crimea

[Colin Smale]

On 2018-10-22 16:34, Mateusz Konieczny wrote:

> I strongly disagree, we map reality.

There is no one true reality, only perceptions. Which reality takes
precedence in your mind, may not be the same for everyone. Reality is
subjective. 

What is the test to apply to decide whether a point is included in
country A or country B? Is it who empties the rubbish bins perhaps? Is
it where the taxes are paid to? Is it what an arbitrary local would
answer to the question "what country are you in?" Putting it in
objective terms, and then applying the criteria consistently,
facilitates getting consensus. 

In the case of disputed borders, there are at least two realities (as
perceived by the parties to the dispute) and possibly a third reality as
perceived by a number of locals - who need to give objective answers to
carefully selected questions so that unintended bias is avoided.___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Fwd: DWG policy on Crimea

[Mateusz Konieczny]

22. Oct 2018 15:51 by yuriastrak...@gmail.com :


> On Mon, Oct 22, 2018 at 8:22 AM Mateusz Konieczny <> matkoni...@tutanota.com 
> > > wrote:
>
>>   
>>> I think a country relation should describe how the specific country think 
>>> of its borders. So if two countries claim the same territory, those two 
>>> relations will overlap.
>>
>> That is absurd and conflict with OSM rule to map what exists. 
>>
>>
> On the contrary, it actually matches OSM rules better than deciding yourself. 
>  When drawing a city outline, you go to that city's government, and get the 
> geoshape from them. 




 

> By extension, if you draw a country, you should use that country's 
> definition.  




I strongly disagree, we map reality. When I map a business I map what exists 
there, not

what the owner claims to be existing. When I map road I map what exists not 
what is

supposed to exist there according to official sources.




When I map the border of a country I map line of control, not an official claim 
of the country.




Maybe "officially claimed border of country" is also mappable but it would not 
be marked as

a border.


 

> By extension, if you draw a country, you should use that country's 
> definition.  




I also disagree as for when it comes to making maps. I see no reason why I 
should be

obligated by official claims by specific country. I may follow them in some 
cases but

it is often undesirable or harmful.


 

> If two country's definitions happen to overlap, we ought to document both.




I am not sure whatever we should map border claims.


 

>>> So when I generate a map for Russia, I have to show Crimea as part of 
>>> Russia.  For Ukraine - as part of Ukraine.  Same for China and India and ...
>>
>> There are also other sources of data. For example to show proper terrain 
>> shape or to show ratings of restaurants and for many others use cases OSM is 
>> not sufficient.
>>
> The argument "it doesn't work for X, therefor we shouldn't make it work for 
> Y" is puzzling.

No, I was just reminding that OSM is not for all and every geographical data.




I am not sure whatever border claims are one of these cases.

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

Re: [OSM-talk] Fwd: DWG policy on Crimea

[Mateusz Konieczny]

22. Oct 2018 16:17 by dieterdre...@gmail.com :


> Am Mo., 22. Okt. 2018 um 15:54 Uhr schrieb Yuri Astrakhan <> 
> yuriastrak...@gmail.com > >:
>
>> On Mon, Oct 22, 2018 at 8:22 AM Mateusz Konieczny <>> 
>> matkoni...@tutanota.com >> > wrote:
>>
>>>   
 I think a country relation should describe how the specific country think 
 of its borders. So if two countries claim the same territory, those two 
 relations will overlap.
>>>
>>> That is absurd and conflict with OSM rule to map what exists. 
>>>
>>>
>> On the contrary, it actually matches OSM rules better than deciding 
>> yourself.  When drawing a city outline, you go to that city's government, 
>> and get the geoshape from them. By extension, if you draw a country, you 
>> should use that country's definition.  If two country's definitions happen 
>> to overlap, we ought to document both.
>
>
> In principle I agree it would be desirable to keep records of "all" claims 
> for a territory, (I can imagine there will be some more rules required, 
> because there are even small groups and individuals claiming authority over 
> territories with very low possibility to be recognized by anyone else, and we 
> might want to exclude those "trolls"). But this should not mean that we do 
> not keep information about who actually controls the territory, and who has 
> claims on it but does not control it. Simply adding a territory to 2 
> countries at the same time can't be the solution.




I am not fundamentally opposed to adding various claims to OSM (though I am not

supporting it either).




But in cases where there is clear who controls given territory main border then 


main administrative boundary should be applied to line of control. 

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

Re: [OSM-talk] Fwd: DWG policy on Crimea

[Martin Koppenhoefer]

Am Mo., 22. Okt. 2018 um 15:54 Uhr schrieb Yuri Astrakhan <
yuriastrak...@gmail.com>:

> On Mon, Oct 22, 2018 at 8:22 AM Mateusz Konieczny 
> wrote:
>
>> I think a country relation should describe how the specific country think
>> of its borders. So if two countries claim the same territory, those two
>> relations will overlap.
>>
>> That is absurd and conflict with OSM rule to map what exists.
>>
> On the contrary, it actually matches OSM rules better than deciding
> yourself.  When drawing a city outline, you go to that city's government,
> and get the geoshape from them. By extension, if you draw a country, you
> should use that country's definition.  If two country's definitions happen
> to overlap, we ought to document both.
>


In principle I agree it would be desirable to keep records of "all" claims
for a territory, (I can imagine there will be some more rules required,
because there are even small groups and individuals claiming authority over
territories with very low possibility to be recognized by anyone else, and
we might want to exclude those "trolls"). But this should not mean that we
do not keep information about who actually controls the territory, and who
has claims on it but does not control it. Simply adding a territory to 2
countries at the same time can't be the solution.

The complicated part seems to state whose version of the country/border it
is. We could have multiple countries for the different possibilities with a
tag (or memberships) that says from which country this is (e.g. for the
Crimea we would have the borders of Russia and of Ucraine according to the
Ucraine and to Russia = 4 versions of the 2 countries). But when those
countries have different disputes with different other countries, this
could become very complex and unmaintainable.

Not sure how to encode for members of a (country)relation that they are the
view of a specific country. Maybe it could be achieved with another
relation type. Border ways could go into border relations (one or more
connected ways) that are part of a border and have tags which say who has
recognized them or whose view it is (this could also be done with a role
like "according_to" and the country as a member, or a simple tag like
according_to=CN). The country relation would be built by referring to those
border relations (it would contain all borders and alternative borders, and
the parts would have the tag that says according to whom).
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Fwd: DWG policy on Crimea

[Yuri Astrakhan]

On Mon, Oct 22, 2018 at 8:22 AM Mateusz Konieczny 
wrote:

> I think a country relation should describe how the specific country think
> of its borders. So if two countries claim the same territory, those two
> relations will overlap.
>
> That is absurd and conflict with OSM rule to map what exists.
>
On the contrary, it actually matches OSM rules better than deciding
yourself.  When drawing a city outline, you go to that city's government,
and get the geoshape from them. By extension, if you draw a country, you
should use that country's definition.  If two country's definitions happen
to overlap, we ought to document both.

> E.g. it would be illegal in some countries to generate political map not
> according to that country's government.
>
> It is also against Chinese law to publish accurate maps of China. It is
> not a sufficient reason to forbid accurate mapping of China in OSM.
>
I did not say we must abide by laws of every country - would not be
possible in case of conflicts. I only said that some countries require you
to draw maps according to their laws.  China is clearly a special case
here, but other countries are much more reasonable, yet still expect you to
draw their maps for them according to their rules.

> So when I generate a map for Russia, I have to show Crimea as part of
> Russia.  For Ukraine - as part of Ukraine.  Same for China and India and ...
>
> There are also other sources of data. For example to show proper terrain
> shape or to show ratings of restaurants and for many others use cases OSM
> is not sufficient.
>
The argument "it doesn't work for X, therefor we shouldn't make it work for
Y" is puzzling. We can easily make it work for the very practical usecase I
outlined -- drawing countries' borders based on the expectations of a
specific user's location.  Country borders are by definition a
controversial topic without a single answer, and as you said, there are
other data sources for it. Yet we add it to OSM because it has a very
tangible value to the data consumers (who don't have to mix-in multiple
data sources for the basic mapping needs).
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Fwd: DWG policy on Crimea

[Mateusz Konieczny]

Can you summarize parts of this article (5k+ words, in "long read" section) 
that are relevant totagging of Russian and Ukrainian border in the Crimea?

22. Oct 2018 00:44 by oleksiy.muzal...@bluewin.ch 
:


> > Hi Martin,
>   
>   Before continuing this discussion further, I would advise to read  
> the amazing article "The demise of the nation state" by Rana  Dasgupta 
> available via this link:> 
> https://www.theguardian.com/news/2018/apr/05/demise-of-the-nation-state-rana-dasgupta
>  
> 
>   
>   The issue of national state boundaries is more profound and  
> ubiquitous than it may seem at first sight. This topic is  controversial 
> and complicated, and Rana Dasgupta's analyses  provides some good 
> starting-point insights.
>   
>   Best regards,
>   Oleksiy
>    
>   On 21.10.18 16:12, Martin Koppenhoefer wrote:
> > 
>> >>   >> Dear all,
>> >> >> we all know how sensible the topic of disputed 
>> boundaries  can be (they are not necessarily a big problem, many 
>> boundary  disputes like between Italy and France about the summit of 
>>  Mont Blanc / Monte Bianco, have little bearing on the actual
>>   life of people).>> 
>> >> >> Therefore we can all be satisfied there is clear 
>> guidance  from the board how to deal with this: the local situation  
>> determines how we map, and the OSMF is explicit here:  
>> “National borders are particularly sensitive. Currently, we  record 
>> one set that, in OpenStreetMap contributor opinion, is  most widely 
>> internationally recognised and best meets  realities on the ground, 
>> generally meaning physical control.”>> 
>> >> >> 
>> https://wiki.osmfoundation.org/w/images/d/d8/DisputedTerritoriesInformation. 
>> >>
>>  pdf >> 
>> >> >> When I recently looked at Crimea I noticed it is still 
>> part  of the Ucraine in OSM: >> 
>> https://www.openstreetmap.org/relation/60199 
>> >> 
>> >> >> As many might know, the current boundary situation for 
>>  Crimea was frozen 4 years ago “for a short time” by the DWG 
>>  and so I asked them about their current position 2 months ago,  and 
>> after I got no reply, tried to remind them 5 weeks ago,  but have 
>> not yet gotten any reply, so I am now opening this  thread here.>>   
>>   
>> >> >> IMHO, for consistency and credibility, we should 
>> either  recognize that Russia is actually controlling Crimea, or we  
>> should update the disputed borders information. As I believe 
>>  the general concept of ground truth for admin boundaries was a  
>> good idea, I would tend to the former.>> 
>> >> >> I also believe the actual situation has already been   
>>ignored for too long. When the thing is still dynamic or/and  
>> we’re in the middle of a conflict it can be wise to step back  and 
>> see for some time how things are evolving, but 4 years are  a lot of 
>> time, something like one year would seem more  reasonable.>> 
>> >> >> What do you think?>> 
>> >> >> Cheers, Martin 
>>   
>>   >> sent from a phone>>   
>> Begin forwarded message:
>> 
>>   >>   
>>> >>> From:>>>  Martin Koppenhoefer <>>> dieterdre...@gmail.com 
>>> 
>>>   >>> Date:>>>  20. August 2018 at 10:42:33 CEST
>>>   >>> To:>>>  >>> d...@osmfoundation.org 
>>> 
>>>   >>> Subject:>>>  >>> DWG policy on Crimea
>>>   
>>> >>>   
>>   
>>> >>> 
>>>   >>>   >>> Dear members of the DWG,>>> 
>>>   
>>>   >>>   >>> as of this question in the help 
>>> forum:>>>   
>>>   >>>   >>> 
>>> https://help.openstreetmap.org/questions/65436/what-is-the-current-position-of-the-dataworkinggroup-on-crimea
>>>  
>>> >>     
>>>   >>>   >>> I kindly invite you to reconsider and 
>>> eventuallyupdate your position on the situation in 
>>> Crimea.>>>   
>>>   >>>   >>> As you have stated i

Re: [OSM-talk] Fwd: DWG policy on Crimea

[Mateusz Konieczny]

21. Oct 2018 23:19 by yuriastrak...@gmail.com :


> I think a country relation should describe how the specific country think of 
> its borders. So if two countries claim the same territory, those two 
> relations will overlap.




That is absurd and conflict with OSM rule to map what exists. 

 
> E.g. it would be illegal in some countries to generate political map not 
> according to that country's government.  




It is also against Chinese law to publish accurate maps of China. It is not a 
sufficient reason 


to forbid accurate mapping of China in OSM.





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



 

> So when I generate a map for Russia, I have to show Crimea as part of Russia. 
>  For Ukraine - as part of Ukraine.  Same for China and India and ...




There are also other sources of data. For example to show proper terrain shape 
or to show

ratings of restaurants and for many others use cases OSM is not sufficient.

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

Re: [OSM-talk] Fwd: DWG policy on Crimea

[Oleksiy Muzalyev]

Hi Martin,

Before continuing this discussion further, I would advise to read the 
amazing article "The demise of the nation state" by Rana Dasgupta 
available via this link: 
https://www.theguardian.com/news/2018/apr/05/demise-of-the-nation-state-rana-dasgupta


The issue of national state boundaries is more profound and ubiquitous 
than it may seem at first sight. This topic is controversial and 
complicated, and Rana Dasgupta's analyses provides some good 
starting-point insights.


Best regards,
Oleksiy

On 21.10.18 16:12, Martin Koppenhoefer wrote:

Dear all,

we all know how sensible the topic of disputed boundaries can be (they 
are not necessarily a big problem, many boundary disputes like between 
Italy and France about the summit of Mont Blanc / Monte Bianco, have 
little bearing on the actual life of people).


Therefore we can all be satisfied there is clear guidance from the 
board how to deal with this: the local situation determines how we 
map, and the OSMF is explicit here: “National borders are particularly 
sensitive. Currently, we record one set that, in OpenStreetMap 
contributor opinion, is most widely internationally recognised and 
best meets realities on the ground, generally meaning physical control.”


https://wiki.osmfoundation.org/w/images/d/d8/DisputedTerritoriesInformation. 
pdf 



When I recently looked at Crimea I noticed it is still part of the 
Ucraine in OSM: https://www.openstreetmap.org/relation/60199


As many might know, the current boundary situation for Crimea was 
frozen 4 years ago “for a short time” by the DWG and so I asked them 
about their current position 2 months ago, and after I got no reply, 
tried to remind them 5 weeks ago, but have not yet gotten any reply, 
so I am now opening this thread here.


IMHO, for consistency and credibility, we should either recognize that 
Russia is actually controlling Crimea, or we should update the 
disputed borders information. As I believe the general concept of 
ground truth for admin boundaries was a good idea, I would tend to the 
former.


I also believe the actual situation has already been ignored for too 
long. When the thing is still dynamic or/and we’re in the middle of a 
conflict it can be wise to step back and see for some time how things 
are evolving, but 4 years are a lot of time, something like one year 
would seem more reasonable.


What do you think?

Cheers, Martin

sent from a phone

Begin forwarded message:

*From:* Martin Koppenhoefer >

*Date:* 20. August 2018 at 10:42:33 CEST
*To:* d...@osmfoundation.org 
*Subject:* *DWG policy on Crimea*


Dear members of the DWG,

as of this question in the help forum:

https://help.openstreetmap.org/questions/65436/what-is-the-current-position-of-the-dataworkinggroup-on-crimea 



I kindly invite you to reconsider and eventually update your position 
on the situation in Crimea.


As you have stated in 2014, this should not be the long term way to 
deal with the situation, and short term is probably coming to an end. 
There is clear guidance by the OSMF board how to deal with disputed 
boundaries (as the situation seems to be more stable than some would 
have liked).


My motivation is not promoting the Russian point of view, but to act 
predictably and consistent wrt sensible topics.


Thank you,
cheers,
Martin



___
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] Fwd: DWG policy on Crimea

[Yuri Astrakhan]

I think a country relation should describe how the specific country think
of its borders. So if two countries claim the same territory, those two
relations will overlap.

While not ideal, this is preferable for many data consumers - when
generating a map, one always has to consider whom it is being generated
for.  E.g. it would be illegal in some countries to generate political map
not according to that country's government.  So when I generate a map for
Russia, I have to show Crimea as part of Russia.  For Ukraine - as part of
Ukraine.  Same for China and India and ...

On Sun, Oct 21, 2018 at 5:11 PM Mateusz Konieczny 
wrote:

>
>
>
> 21. Oct 2018 15:12 by dieterdre...@gmail.com:
>
> Therefore we can all be satisfied there is clear guidance from the board
> how to deal with this: the local situation determines how we map, and the
> OSMF is explicit here: “National borders are particularly sensitive.
> Currently, we record one set that, in OpenStreetMap contributor opinion, is
> most widely internationally recognised and best meets realities on the
> ground, generally meaning physical control.”
>
>
> https://wiki.osmfoundation.org/w/images/d/d8/DisputedTerritoriesInformation.
> 
> pdf
>
> When I recently looked at Crimea I noticed it is still part of the Ucraine
> in OSM: https://www.openstreetmap.org/relation/60199
>
>
> Yes, situation on the ground is quite clear here.
>
>
> No matter whatever we like it or not, Crimea is no longer controlled by
> Ukraine and situation
>
> here is quite clear, unlike other affected regions.
>
> We should apply here "Note that OSM follows On the Ground Rule
> .
> Boundaries recorded in
> OpenStreetMap are ones that are the most widely internationally recognised
> and best meets realities
> on the ground, generally meaning physical control."
> ___
> 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] Fwd: DWG policy on Crimea

[Mateusz Konieczny]

21. Oct 2018 15:12 by dieterdre...@gmail.com :


> Therefore we can all be satisfied there is clear guidance from the board how 
> to deal with this: the local situation determines how we map, and the OSMF is 
> explicit here: “National borders are particularly sensitive. Currently, we 
> record one set that, in OpenStreetMap contributor opinion, is most widely 
> internationally recognised and best meets realities on the ground, generally 
> meaning physical control.”
> https://wiki.osmfoundation.org/w/images/d/d8/DisputedTerritoriesInformation. 
> >
>  pdf 
> When I recently looked at Crimea I noticed it is still part of the Ucraine in 
> OSM: > https://www.openstreetmap.org/relation/60199 
> 




Yes, situation on the ground is quite clear here.




No matter whatever we like it or not, Crimea is no longer controlled by Ukraine 
and situation

here is quite clear, unlike other affected regions.

We should apply here "Note that OSM follows On the Ground Rule 
. Boundaries 
recorded inOpenStreetMap are ones that are the most widely internationally 
recognised and best meets realitieson the ground, generally meaning physical 
control."
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Fwd: DWG policy on Crimea

[Imre Samu]

> When I recently looked at Crimea I noticed it is still part of the
Ucraine in OSM: https://www.openstreetmap.org/relation/60199

And part of Russia:
https://www.openstreetmap.org/relation/60189#map=6/45.014/33.873&layers=C

Imre

Martin Koppenhoefer  ezt írta (időpont: 2018. okt.
21., V, 15:15):

> Dear all,
>
> we all know how sensible the topic of disputed boundaries can be (they are
> not necessarily a big problem, many boundary disputes like between Italy
> and France about the summit of Mont Blanc / Monte Bianco, have little
> bearing on the actual life of people).
>
> Therefore we can all be satisfied there is clear guidance from the board
> how to deal with this: the local situation determines how we map, and the
> OSMF is explicit here: “National borders are particularly sensitive.
> Currently, we record one set that, in OpenStreetMap contributor opinion, is
> most widely internationally recognised and best meets realities on the
> ground, generally meaning physical control.”
>
>
> https://wiki.osmfoundation.org/w/images/d/d8/DisputedTerritoriesInformation.
> 
> pdf
>
> When I recently looked at Crimea I noticed it is still part of the Ucraine
> in OSM: https://www.openstreetmap.org/relation/60199
>
> As many might know, the current boundary situation for Crimea was frozen 4
> years ago “for a short time” by the DWG and so I asked them about their
> current position 2 months ago, and after I got no reply, tried to remind
> them 5 weeks ago, but have not yet gotten any reply, so I am now opening
> this thread here.
>
> IMHO, for consistency and credibility, we should either recognize that
> Russia is actually controlling Crimea, or we should update the disputed
> borders information. As I believe the general concept of ground truth for
> admin boundaries was a good idea, I would tend to the former.
>
> I also believe the actual situation has already been ignored for too long.
> When the thing is still dynamic or/and we’re in the middle of a conflict it
> can be wise to step back and see for some time how things are evolving, but
> 4 years are a lot of time, something like one year would seem more
> reasonable.
>
> What do you think?
>
> Cheers, Martin
>
> sent from a phone
>
> Begin forwarded message:
>
> *From:* Martin Koppenhoefer 
> *Date:* 20. August 2018 at 10:42:33 CEST
> *To:* d...@osmfoundation.org
> *Subject:* *DWG policy on Crimea*
>
>
> Dear members of the DWG,
>
> as of this question in the help forum:
>
>
> https://help.openstreetmap.org/questions/65436/what-is-the-current-position-of-the-dataworkinggroup-on-crimea
>
>
> I kindly invite you to reconsider and eventually update your position on
> the situation in Crimea.
>
> As you have stated in 2014, this should not be the long term way to deal
> with the situation, and short term is probably coming to an end. There is
> clear guidance by the OSMF board how to deal with disputed boundaries (as
> the situation seems to be more stable than some would have liked).
>
> My motivation is not promoting the Russian point of view, but to act
> predictably and consistent wrt sensible topics.
>
> Thank you,
> cheers,
> Martin
>
> ___
> 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] Fwd: DWG policy on Crimea

[_ dikkeknodel]

Hi all,

I fully support the position summarized by statement “As you have stated in 
2014, this should not be the long term way to deal with the situation, and 
short term is probably coming to an end.” If the DWG does not share this 
position, they should provide an argument for it.

Cheers,
dikkeknodel


Van: Martin Koppenhoefer 
Verzonden: Sunday, October 21, 2018 3:12:03 PM
Aan: talk@openstreetmap.org
Onderwerp: [OSM-talk] Fwd: DWG policy on Crimea

Dear all,

we all know how sensible the topic of disputed boundaries can be (they are not 
necessarily a big problem, many boundary disputes like between Italy and France 
about the summit of Mont Blanc / Monte Bianco, have little bearing on the 
actual life of people).

Therefore we can all be satisfied there is clear guidance from the board how to 
deal with this: the local situation determines how we map, and the OSMF is 
explicit here: “National borders are particularly sensitive. Currently, we 
record one set that, in OpenStreetMap contributor opinion, is most widely 
internationally recognised and best meets realities on the ground, generally 
meaning physical control.”

https://wiki.osmfoundation.org/w/images/d/d8/DisputedTerritoriesInformation.<https://wiki.osmfoundation.org/w/images/d/d8/DisputedTerritoriesInformation.pdf>pdf

When I recently looked at Crimea I noticed it is still part of the Ucraine in 
OSM: https://www.openstreetmap.org/relation/60199

As many might know, the current boundary situation for Crimea was frozen 4 
years ago “for a short time” by the DWG and so I asked them about their current 
position 2 months ago, and after I got no reply, tried to remind them 5 weeks 
ago, but have not yet gotten any reply, so I am now opening this thread here.

IMHO, for consistency and credibility, we should either recognize that Russia 
is actually controlling Crimea, or we should update the disputed borders 
information. As I believe the general concept of ground truth for admin 
boundaries was a good idea, I would tend to the former.

I also believe the actual situation has already been ignored for too long. When 
the thing is still dynamic or/and we’re in the middle of a conflict it can be 
wise to step back and see for some time how things are evolving, but 4 years 
are a lot of time, something like one year would seem more reasonable.

What do you think?

Cheers, Martin

sent from a phone

Begin forwarded message:

From: Martin Koppenhoefer 
mailto:dieterdre...@gmail.com>>
Date: 20. August 2018 at 10:42:33 CEST
To: d...@osmfoundation.org<mailto:d...@osmfoundation.org>
Subject: DWG policy on Crimea


Dear members of the DWG,

as of this question in the help forum:

https://help.openstreetmap.org/questions/65436/what-is-the-current-position-of-the-dataworkinggroup-on-crimea

I kindly invite you to reconsider and eventually update your position on the 
situation in Crimea.

As you have stated in 2014, this should not be the long term way to deal with 
the situation, and short term is probably coming to an end. There is clear 
guidance by the OSMF board how to deal with disputed boundaries (as the 
situation seems to be more stable than some would have liked).

My motivation is not promoting the Russian point of view, but to act 
predictably and consistent wrt sensible topics.

Thank you,
cheers,
Martin
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Fwd: DWG policy on Crimea

[Martin Koppenhoefer]

Dear all,

we all know how sensible the topic of disputed boundaries can be (they are not 
necessarily a big problem, many boundary disputes like between Italy and France 
about the summit of Mont Blanc / Monte Bianco, have little bearing on the 
actual life of people).

Therefore we can all be satisfied there is clear guidance from the board how to 
deal with this: the local situation determines how we map, and the OSMF is 
explicit here: “National borders are particularly sensitive. Currently, we 
record one set that, in OpenStreetMap contributor opinion, is most widely 
internationally recognised and best meets realities on the ground, generally 
meaning physical control.”

https://wiki.osmfoundation.org/w/images/d/d8/DisputedTerritoriesInformation.pdf 

When I recently looked at Crimea I noticed it is still part of the Ucraine in 
OSM: https://www.openstreetmap.org/relation/60199

As many might know, the current boundary situation for Crimea was frozen 4 
years ago “for a short time” by the DWG and so I asked them about their current 
position 2 months ago, and after I got no reply, tried to remind them 5 weeks 
ago, but have not yet gotten any reply, so I am now opening this thread here.

IMHO, for consistency and credibility, we should either recognize that Russia 
is actually controlling Crimea, or we should update the disputed borders 
information. As I believe the general concept of ground truth for admin 
boundaries was a good idea, I would tend to the former.

I also believe the actual situation has already been ignored for too long. When 
the thing is still dynamic or/and we’re in the middle of a conflict it can be 
wise to step back and see for some time how things are evolving, but 4 years 
are a lot of time, something like one year would seem more reasonable.

What do you think?

Cheers, Martin 

sent from a phone

Begin forwarded message:

> From: Martin Koppenhoefer 
> Date: 20. August 2018 at 10:42:33 CEST
> To: d...@osmfoundation.org
> Subject: DWG policy on Crimea
> 
> 
> Dear members of the DWG,
> 
> as of this question in the help forum:
> 
> https://help.openstreetmap.org/questions/65436/what-is-the-current-position-of-the-dataworkinggroup-on-crimea
>  
> 
> I kindly invite you to reconsider and eventually update your position on the 
> situation in Crimea.
> 
> As you have stated in 2014, this should not be the long term way to deal with 
> the situation, and short term is probably coming to an end. There is clear 
> guidance by the OSMF board how to deal with disputed boundaries (as the 
> situation seems to be more stable than some would have liked).
> 
> My motivation is not promoting the Russian point of view, but to act 
> predictably and consistent wrt sensible topics.
> 
> Thank you,
> cheers,
> Martin 
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Fwd: 2 Great Lakes missing

[Christoph Hormann]

On Monday 13 August 2018, SelfishSeahorse wrote:
>
> Thanks for the tip; I din't think of it. Actually my computer had
> more difficulties to calculate that i had to find the errors. :-)

Note checking this kind of errors on large multipolygons is not really 
that difficult.  For each of the big lakes that is a few dozen MB of 
download via overpass API and then a few seconds with osmium to 
assemble the multipolygon.  You can easily set this up to run on a 
daily basis to check a few lakes you want to keep an eye on.

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

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

Re: [OSM-talk] Fwd: 2 Great Lakes missing

[James]

Yeah those great "lakes" are such a massive relations... I think I can make
toast on my computer while it's calculating the errors. Thanks for fixing
it Selfish Seahorse

On Mon., Aug. 13, 2018, 9:12 a.m. SelfishSeahorse, <
selfishseaho...@gmail.com> wrote:

> On Mon, 13 Aug 2018 at 14:01, Christoph Hormann  wrote:
> >
> >
> > Note you can easily check if there are broken multipolygons in the OSM
> > inspector:
> >
> >
> http://tools.geofabrik.de/osmi/?view=areas&lon=-84.14378&lat=46.10509&zoom=8
> >
> > If a lake multipolygon is broken the lake outline will be shown as
> > context there and the location of the error usually in red (self
> > interaection) or magenta (ring not closed).
>
> Thanks for the tip; I din't think of it. Actually my computer had more
> difficulties to calculate that i had to find the errors. :-)
>
> Regards
> Markus
>
> ___
> 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] Fwd: 2 Great Lakes missing

[SelfishSeahorse]

On Mon, 13 Aug 2018 at 14:01, Christoph Hormann  wrote:
>
>
> Note you can easily check if there are broken multipolygons in the OSM
> inspector:
>
> http://tools.geofabrik.de/osmi/?view=areas&lon=-84.14378&lat=46.10509&zoom=8
>
> If a lake multipolygon is broken the lake outline will be shown as
> context there and the location of the error usually in red (self
> interaection) or magenta (ring not closed).

Thanks for the tip; I din't think of it. Actually my computer had more
difficulties to calculate that i had to find the errors. :-)

Regards
Markus

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

Re: [OSM-talk] Fwd: 2 Great Lakes missing

[SelfishSeahorse]

Hi!

On Mon, 13 Aug 2018 at 13:50, Tom Hughes  wrote:
>
> You should see the changes at z13+ but z0-12 are only rendered once a
> month or when the style changes.

Thanks for your explanation. This also explains why it was not noticed
that the lakes had disappeared until about a month after the faulty
edits at Lake Huron.

Regards
Markus

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

Re: [OSM-talk] Fwd: 2 Great Lakes missing

[Christoph Hormann]

Note you can easily check if there are broken multipolygons in the OSM 
inspector:

http://tools.geofabrik.de/osmi/?view=areas&lon=-84.14378&lat=46.10509&zoom=8

If a lake multipolygon is broken the lake outline will be shown as 
context there and the location of the error usually in red (self 
interaection) or magenta (ring not closed).

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

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

Re: [OSM-talk] Fwd: 2 Great Lakes missing

[Tom Hughes]

You should see the changes at z13+ but z0-12 are only rendered once a
month or when the style changes.

Tom

On 13/08/18 12:36, SelfishSeahorse wrote:

Apparently I sent the message only to James ... So here it is for the
rest of you. eanwhile the lakes are rendered):

-- Forwarded message -

Hi

There were quite a few problems with these multipolygons (overlapping
and unclosed ways, no role, inner ways belonging to wrong
multipolygon), which i've just fixed:




The multipolygons should be okay now – at least JOSM and i couldn't
find any more problems. :-) However they still don't render ... Could
it be that this is has to do with these server issues:

?

Regards

Markus

On Fri, 10 Aug 2018 at 02:25, James  wrote:


someone probably broke them again... happens quite often sadly...

On Thu., Aug. 9, 2018, 9:05 p.m. Daniel Koć,  wrote:


Hi,

Is anybody aware what happened to Lake Superior and Lake Huron?

https://www.openstreetmap.org/relation/4039486

https://www.openstreetmap.org/relation/1205151


They were changed 20 and 3 days ago, respectively, and they stopped
being rendered both on default and on humanitarian map.


--
"My method is uncertain/ It's a mess but it's working" [F. Apple]


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




--
Tom Hughes (t...@compton.nu)
http://compton.nu/

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

[OSM-talk] Fwd: 2 Great Lakes missing

[SelfishSeahorse]

Apparently I sent the message only to James ... So here it is for the
rest of you. eanwhile the lakes are rendered):

-- Forwarded message -

Hi

There were quite a few problems with these multipolygons (overlapping
and unclosed ways, no role, inner ways belonging to wrong
multipolygon), which i've just fixed:




The multipolygons should be okay now – at least JOSM and i couldn't
find any more problems. :-) However they still don't render ... Could
it be that this is has to do with these server issues:

?

Regards

Markus

On Fri, 10 Aug 2018 at 02:25, James  wrote:
>
> someone probably broke them again... happens quite often sadly...
>
> On Thu., Aug. 9, 2018, 9:05 p.m. Daniel Koć,  wrote:
>>
>> Hi,
>>
>> Is anybody aware what happened to Lake Superior and Lake Huron?
>>
>> https://www.openstreetmap.org/relation/4039486
>>
>> https://www.openstreetmap.org/relation/1205151
>>
>>
>> They were changed 20 and 3 days ago, respectively, and they stopped
>> being rendered both on default and on humanitarian map.
>>
>>
>> --
>> "My method is uncertain/ It's a mess but it's working" [F. Apple]

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

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

[Clifford Snow]

I echo Bryan - this is a much needed feature. I started incorporating
OSMCha into my review of new users in my area. That I could easily capture
"good and bad" edits and post a comment to the user at the same time is
nice. When I do come across a bad edit, and it doesn't happen often, I post
a more complete changeset message. For example, a yesterday a new user made
one bad and one good edit. The bad edit was to add a natural=water
rectangle in a back yard, his I'm assuming. It was so large you could fit
two or more olympic sized swimming pools in the same area. The other edit
was to add a parking lot. I often even post tips when they make a good edit
but the edit could use some improvement - often squaring houses.

OSMCha offers us the chance to catch problems early which is going to
discourage vandalism by removing any trace of it. That way the new user
can't show their friends how they added say a pokemon spawning feature next
to their house.

Willie - thanks for the feature

Clifford

On Fri, Jan 12, 2018 at 6:17 AM, Erwin Olario  wrote:

>
> reposting an earlier reply, which i mistakenly sent directly just to
> Michael
> -- Forwarded message -
> From: Erwin Olario 
> Date: Fri, Jan 12, 2018 at 10:15 PM
> Subject: Re: [OSM-talk] Automatically generated changeset discussion
> comments by OSMCha
> To: Michael Reichert 
>
>
> I believe it's a good idea. At present, any OSM user (and all OsmCha
> users, are OSM users) can leave any comment to a changeset, whether or not
> the mapper asked for any.
>
> Earlier, I filed a ticket to enhance OsmCha behavior. Instead of posting a
> default message, the reviewer should leave details outlining how the
> changeset could be improved (or why they think it's bad.)
>
> [0]: https://github.com/mapbox/osmcha-frontend/issues/248
>
> On Fri, Jan 12, 2018 at 10:10 PM Michael Reichert 
> wrote:
>
>> Hi,
>>
>> OSMCha started posting comments to changesets a few days ago when a user
>> marks a changeset as good or bad.
>> https://www.openstreetmap.org/user/wille/diary/43101
>> I would like to ask the author(s) of OSMCha to disable this feature.
>>
>> We expect to read all mappers incoming message (personal messages and
>> changeset comments). If third-party tools start to post comments to lots
>> of changesets automatically, this is some kind of spamming. If OSM sends
>> to much emails to a user, the user will probably ignore them or treat
>> them as spam.
>>
>> I think that OSMCha should not post a comment automatically except if
>> the user has explicitly asked for feedback or there are quality issues
>> regarding the edit (mistakes, vandalism, guideline violations or
>> anything else which makes it necessary to talk to the user).
>>
>> I post this email to this mailing list instead of filing a bug report a
>> Github [1] because I want to bring this problem to the wider audience
>> and initiate a general discussion on the acceptable usage of the
>> changeset comments API.
>>
>> What are your thoughts and opinions on this issue?
>>
>> Best regards
>>
>> Michael
>>
>>
>> [1] Btw, which Github repository would be the correct one the file the
>> bug report at?
>> https://duckduckgo.com/?q=osmcha+github&t=ffsb&ia=web
>>
>>
>> --
>> Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
>> ausgenommen)
>> I prefer GPG encryption of emails. (does not apply on mailing lists)
>>
>> ___
>> talk mailing list
>> talk@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk
>>
>
>
> --
>
> /Erwin Olario
>
> e: er...@ngnuity.xyz | v/m: https://t.me/GOwin | s:
> https://mstdn.io/@GOwin
>
>
> --
>
> /Erwin Olario
>
> e: er...@ngnuity.xyz | v/m: https://t.me/GOwin | s:
> https://mstdn.io/@GOwin
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
>


-- 
@osm_seattle
osm_seattle.snowandsnow.us
OpenStreetMap: Maps with a human touch
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[Erwin Olario]

reposting an earlier reply, which i mistakenly sent directly just to Michael
-- Forwarded message -
From: Erwin Olario 
Date: Fri, Jan 12, 2018 at 10:15 PM
Subject: Re: [OSM-talk] Automatically generated changeset discussion
comments by OSMCha
To: Michael Reichert 


I believe it's a good idea. At present, any OSM user (and all OsmCha users,
are OSM users) can leave any comment to a changeset, whether or not the
mapper asked for any.

Earlier, I filed a ticket to enhance OsmCha behavior. Instead of posting a
default message, the reviewer should leave details outlining how the
changeset could be improved (or why they think it's bad.)

[0]: https://github.com/mapbox/osmcha-frontend/issues/248

On Fri, Jan 12, 2018 at 10:10 PM Michael Reichert 
wrote:

> Hi,
>
> OSMCha started posting comments to changesets a few days ago when a user
> marks a changeset as good or bad.
> https://www.openstreetmap.org/user/wille/diary/43101
> I would like to ask the author(s) of OSMCha to disable this feature.
>
> We expect to read all mappers incoming message (personal messages and
> changeset comments). If third-party tools start to post comments to lots
> of changesets automatically, this is some kind of spamming. If OSM sends
> to much emails to a user, the user will probably ignore them or treat
> them as spam.
>
> I think that OSMCha should not post a comment automatically except if
> the user has explicitly asked for feedback or there are quality issues
> regarding the edit (mistakes, vandalism, guideline violations or
> anything else which makes it necessary to talk to the user).
>
> I post this email to this mailing list instead of filing a bug report a
> Github [1] because I want to bring this problem to the wider audience
> and initiate a general discussion on the acceptable usage of the
> changeset comments API.
>
> What are your thoughts and opinions on this issue?
>
> Best regards
>
> Michael
>
>
> [1] Btw, which Github repository would be the correct one the file the
> bug report at?
> https://duckduckgo.com/?q=osmcha+github&t=ffsb&ia=web
>
>
> --
> Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
> ausgenommen)
> I prefer GPG encryption of emails. (does not apply on mailing lists)
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>


-- 

/Erwin Olario

e: er...@ngnuity.xyz | v/m: https://t.me/GOwin | s: https://mstdn.io/@GOwin


-- 

/Erwin Olario

e: er...@ngnuity.xyz | v/m: https://t.me/GOwin | s: https://mstdn.io/@GOwin
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Fwd: Job posting - GIS Librarian

[Federico Leva (Nemo)]

  Messaggio inoltrato 
Oggetto: [SCHOLCOMM] Job posting - GIS Librarian
Data: Tue, 19 Dec 2017 17:23:18 +
Mittente: "Lyon, Colleen E"

Come join us in Austin!
Cheers-Colleen


GIS and Geospatial Data Coordinator - Librarian II
University of Texas Libraries, the University of Texas at Austin
Salary is $55,000+ per year, negotiable depending on qualifications
First review of applicants is Tuesday, January 16, 2018

The UT Libraries (UTL) seeks to be a pre-eminent and active partner 
within the rich education and research ecosystem at UT through expansive 
collections and digital content, and with innovative services, programs, 
tools and partnerships. We help develop critical thinkers and global 
citizens who transform lives. The Academic Engagement Division supports 
these goals through its Research Support and Digital Initiatives, 
Teaching and Learning, and Scholarly Resources departments.


The Research Support and Digital Initiatives department is comprised of 
a combination of subject liaisons and domain experts who collaborate 
with UTL colleagues and other campus partners to grow, enhance, and 
manage a suite of tools and services that support the research 
lifecycle, promote digital scholarship and digital collections, and 
advance new and emerging modes of scholarship. This work involves 
contributing to the design and implementation of library workflows and 
technology infrastructure, and building a community of practice around 
digital scholarship at UT.


We also work with students, faculty, staff and UTL colleagues to advance 
their research, scholarship, and teaching, through a combination of 
resources, education, outreach, and personal consultation.
UTL librarians and domain experts are responsible for envisioning, 
designing, implementing, assessing and reporting on services and 
activities that support the goals and purpose of their specific 
positions. All are expected to function with a high degree of 
independence as well as in teams to ensure progress toward library and 
unit objectives. They are also expected to work in a collegial, 
collaborative, and professional fashion, and to engage in activities 
that contribute to the mission of both UTL and the University of Texas.


The GIS and Geospatial Data Coordinator will provide leadership for, 
develop and promote GIS and geospatial data services for faculty, staff, 
and students by providing tools and resources to facilitate the 
discovery, access, management, and analysis of geospatial data across 
all disciplines at UT. Additional duties are described in the posting. 
The position reports to the Data Management Coordinator and works 
together with her and the Research Support and Digital Initiatives 
department to support UT affiliate GIS needs.


To learn more about this position and to apply, please see posting 
https://utdirect.utexas.edu/apps/hr/jobs/nlogon/171214010086


First review of applicants is Tuesday, January 16, 2018.

UTL welcomes and respects all individuals and communities by valuing and 
consciously maintaining awareness of diverse perspectives and 
experiences. We believe inclusivity is critical to fostering excellence 
in all of our endeavors, and we promote diversity in our collections and 
the services that we provide as well as in our recruiting, hiring, and 
retention practices.




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

[OSM-talk] Fwd: FW: Open survey on participation biases in OSM

[Zoe Gardner]

Dear OSM talk subscriber



A few weeks ago I posted a diary entry introducing myself, my interests in
OSM and showcasing an upcoming survey for OSM editors. I am a Research
Fellow in the Nottingham Geospatial Institute at the University of
Nottingham, interested in participation biases in geospatial crowdsourced
projects such as OSM and other Volunteered Geographical Information (VGI)
projects. My current research project is concerned with the way in which
participation biases in OSM may potentially affect the usability of the
data that is collected and subsequently what is available to location based
service providers which use OSM as their primary geospatial database.



You can read the full  entry by clicking on my diary entries in this link:



https://www.openstreetmap.org/user/Geospa_gal




The project is motivated by recent research that has found a strong male
bias in OSM participation. This has led to assertions that various
geospatial knowledge could be under represented or poorly recorded on the
map. However, the actual consequences of this bias remain little explored
or reported. By collecting information about contributors to OSM, which can
then be analyzed along with their editing patterns, the impacts of this
bias might begin to be measured and therefore better understood. I have
therefore published an online survey designed to collect information
directly from OSM editors and I would like to invite as many of you as
possible to participate. The survey is anonymous and takes a couple of
minutes to complete.



If you are an OSM contributor and are interested in or would like to
participate in the study, please click on the link below, which will take
you to the Bristol Online Survey website where you will find more
information and an opportunity to participate in the survey. As a small
incentive, at the close of the survey in a few weeks’ time, 60 respondents
will be drawn at random to receive a £15 Amazon voucher.



To participate in the survey, click on the link below:



https://nottingham.onlinesurveys.ac.uk/osm-user-profiles



Please do think about participating. It is hoped that knowledge about the
way participation biases impact on crowdsourced maps will enable new
strategies to be developed to address any resulting voids in the geospatial
information provided by amateur mappers. In turn this could strengthen the
role played by platforms such as OSM in urban planning and sustainability
and raise the profile of the important mapping work that you all do.



In the meantime, if you would like to know more about me, my research
activities or the project, please visit my University webpage (link below)
and do not hesitate to get in touch directly or via the OSM messaging
service.



https://www.nottingham.ac.uk/engineering/people/zoe.gardner



Thank you

Zoe







This message and any attachment are intended solely for the addressee
and may contain confidential information. If you have received this
message in error, please send it back to me, and immediately delete it.

Please do not use, copy or disclose the information contained in this
message or in any attachment.  Any views or opinions expressed by the
author of this email do not necessarily reflect the views of the
University of Nottingham.

This message has been checked for viruses but the contents of an
attachment may still contain software viruses which could damage your
computer system, you are advised to perform your own checks. Email
communications with the University of Nottingham may be monitored as
permitted by UK legislation.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Fwd: [Wikimedia-l] [fellowship] Opportunity for people working on "open projects that support a healthy Internet."

[Pine W]

Forwarding.

Pine


-- Forwarded message --
From: Melody Kramer 
Date: Mon, Jul 10, 2017 at 2:26 PM
Subject: [Wikimedia-l] [fellowship] Opportunity for people working on "open
projects that support a healthy Internet."
To: wikimedi...@lists.wikimedia.org


Hi all,

I wanted to pass along an opportunity that I saw earlier today via Twitter:
https://medium.com/read-write-participate/work-in-the-open-
with-mozilla-1410be0a83b2

It sets up people working on "open projects that support a healthy
Internet" with a mentor, a cohort of like-minded people from all over the
world, and a trip to Mozfest, which is a London-based open Internet
conference I've attended/presented at in past years and found really
mind-expanding due to the cross-disciplinary conversations that take place.

You can see previous projects here: https://mozilla.github.
io/leadership-training/round-3/projects/ — it looks like there's quite a
broad cross-section and many of the projects across the movement might be
applicable. The post notes participants will learn about "best practices
for project setup and communication, tools for collaboration, community
building, and running events."

Thank you to Leila for suggesting I pass this along to this listserv. Feel
free to share it broadly.


- Mel


--
Melody Kramer 
Senior Audience Development Manager
Read a random featured article from Wikipedia!


mkra...@wikimedia.org
___
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/
wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/
wiki/Wikimedia-l
New messages to: wikimedi...@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,

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

[OSM-talk] Fwd: Call for scholarship applications to attend State of the Map Asia 2017

[maning sambale]

Call for scholarships for SotM-Asia 2017 is now open.
http://stateofthemap.asia/scholarships.html

-- Forwarded message --
From: kshitiz khanal 
Date: Mon, May 8, 2017 at 1:05 PM
Subject: Call for scholarship applications to attend State of the Map Asia
2017
To: Nama Budhathoki , Pradip Khatiwada <
youthpra...@gmail.com>


Dear OSM community member,
​​
​We want to welcome you to State of the Map Asia 2017, which will be
organized in Kathmandu, Nepal on September 23 - 24, hosted by Kathmandu
Living Labs and OSM community of Nepal.

The event website is now live at: http://stateofthemap.asia/

A call for scholarships is now open. Please use this link

to apply.

Call to apply for scholarships to attend State of the Map Asia is now open.
Please fill this form to apply for receiving support to attend SotM Asia
2017. We can not guarantee that we can provide scholarships for all
applicants, but we are trying to gather resources for as many as possible.
The deadline for application is June 10, 2017.

We need your support to make this a successful event and help foster the
growth of OSM in Asia and beyond.

Please refer to the website for further details.

With best regards,

Kshitiz Khanal
Researcher, Open Data and OpenStreetMap
Kathmandu Living Labs​



-- 
cheers,
maning
--
"Freedom is still the most radical idea of all" -N.Branden
https://epsg4253.wordpress.com/
http://twitter.com/maningsambale
--
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Fwd: [Wikidata] Significant change: new data type for geoshapes

[Pine W]

Schedule update below.

Pine


-- Forwarded message --
From: Léa Lacroix 
Date: Mon, Apr 3, 2017 at 1:26 AM
Subject: Re: [Wikidata] Significant change: new data type for geoshapes
To: wikidata-t...@lists.wikimedia.org, "Discussion list for the Wikidata
project." , pywiki...@lists.wikimedia.org


Hello,
Small change: due to the server switch
 and Easter
holiday in Germany, the deployment is delayed to April 24th. Thanks for
your patience.

On 29 March 2017 at 13:34, Léa Lacroix  wrote:

> Hello all,
>
> We’ve been working on a new data type that allows you to link to the 
> *geographical
> shapes* that are now stored on Commons. This data type will be deployed
> on Wikidata on *April 17th*.
>
> This data type refers to the geographical shapes that are enabled on
> Wikimedia Commons since the beginning of this year. Here you can find
> more information about this .
>
> The property creators will be able to create properties with this geoshape
> data type by selecting “Geographical shape” in the data type list.
>
> When the property is created, you can use it in statements, and when
> filling the value, if you start typing a string, you can choose the name of
> a geoshape in the list of what exists on Commons.
>
> [image: Screenshot test geoshape in Wikidata.png]
> 
>
>
> One thing to note: We currently do not export statements that use this
> datatype to RDF. They can therefore not be queried in the Wikidata Query
> Service. The reason is that we are still waiting for geoshapes to get
> stable URIs. This is handled in this ticket
> .
>
> Before the deployment, you can test it on http://test.wikidata.org (see
> for example the property “geotest” on Q22
> ).
> If you have any question, feel free to ask!
>
> Cheers,
>
> --
> Léa Lacroix
> Project Manager Community Communication for Wikidata
>
> Wikimedia Deutschland e.V.
> Tempelhofer Ufer 23-24
> 10963 Berlin
> www.wikimedia.de
>
> Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
>
> Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg
> unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das Finanzamt
> für Körperschaften I Berlin, Steuernummer 27/029/42207.
>



-- 
Léa Lacroix
Project Manager Community Communication for Wikidata

Wikimedia Deutschland e.V.
Tempelhofer Ufer 23-24
10963 Berlin
www.wikimedia.de

Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.

Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das Finanzamt für
Körperschaften I Berlin, Steuernummer 27/029/42207.

___
Wikidata mailing list
wikid...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Fwd: [HOT] Call for Logos for State of the Map Asia 2017

[maning sambale]

FYI, State of the Map Asia 2017 will happen in Kathmandu Sept-Oct 2017
(dates TBD).  Please help us design the logo.

-- Forwarded message --
From: kshitiz khanal 
Date: Thu, Mar 30, 2017 at 10:23 AM
Subject: [HOT] Call for Logos for State of the Map Asia 2017
To: h...@openstreetmap.org, sotm-a...@openstreetmap.org,
talk...@openstreetmap.org


Dear all,

The State of the Map Asia 2017 working group is pleased to announce a
call for logo designs. We need your help to build a strong
recognisable logo for State of the Map Asia 2017 (SotM Asia)
conference taking place in Kathmandu, Nepal. The conference is
OpenStreetMap’s annual gathering of the community, interested parties
and others in Asia.

We have put together a Design Brief which outlines what we were
looking for in a logo. Entrants could be an individual or team of
people, or even a design company.

All entries will be considered to give copyright ownership to SotM so
that it can be used across different mediums. Entries have to appear
on the wiki page State Of The Map Asia 2017/Logo entries by 23:59 UTC
(before midnight) on 15th of April 2017. The SotM Asia 2017 working
group will decide by vote the logo to go with.

The winning entry will be rewarded with one full weekend ticket to
State of the Map Asia 2017!

For guidelines and other details, please refer to
https://wiki.openstreetmap.org/wiki/Call_for_logo_sotm_asia_2017


Regards,


Kshitiz Khanal

Researcher

Kathmandu Living Labs




___
HOT mailing list
h...@openstreetmap.org
https://lists.openstreetmap.org/listinfo/hot



-- 
cheers,
maning
--
"Freedom is still the most radical idea of all" -N.Branden
https://epsg4253.wordpress.com/
http://twitter.com/maningsambale
--

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

Re: [OSM-talk] Fwd: [Wikidata] Significant change: new data type for geoshapes

[James]

very nice.

On Wed, Mar 29, 2017 at 2:39 PM, Pine W  wrote:

> Forwarding.
>
> Pine
>
>
> -- Forwarded message --
> From: Léa Lacroix 
> Date: Wed, Mar 29, 2017 at 4:34 AM
> Subject: [Wikidata] Significant change: new data type for geoshapes
> To: wikidata-t...@lists.wikimedia.org, "Discussion list for the Wikidata
> project." , pywiki...@lists.wikimedia.org
>
>
> Hello all,
>
> We’ve been working on a new data type that allows you to link to the 
> *geographical
> shapes* that are now stored on Commons. This data type will be deployed
> on Wikidata on *April 17th*.
>
> This data type refers to the geographical shapes that are enabled on
> Wikimedia Commons since the beginning of this year. Here you can find
> more information about this .
>
> The property creators will be able to create properties with this geoshape
> data type by selecting “Geographical shape” in the data type list.
>
> When the property is created, you can use it in statements, and when
> filling the value, if you start typing a string, you can choose the name of
> a geoshape in the list of what exists on Commons.
>
> [image: Screenshot test geoshape in Wikidata.png]
> 
>
>
> One thing to note: We currently do not export statements that use this
> datatype to RDF. They can therefore not be queried in the Wikidata Query
> Service. The reason is that we are still waiting for geoshapes to get
> stable URIs. This is handled in this ticket
> .
>
> Before the deployment, you can test it on http://test.wikidata.org (see
> for example the property “geotest” on Q22
> ).
> If you have any question, feel free to ask!
>
> Cheers,
>
> --
> Léa Lacroix
> Project Manager Community Communication for Wikidata
>
> Wikimedia Deutschland e.V.
> Tempelhofer Ufer 23-24
> 10963 Berlin
> www.wikimedia.de
>
> Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
>
> Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg
> unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das Finanzamt
> für Körperschaften I Berlin, Steuernummer 27/029/42207.
>
> ___
> Wikidata mailing list
> wikid...@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata
>
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
>


-- 
外に遊びに行こう！
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Fwd: [Wikidata] Significant change: new data type for geoshapes

[Pine W]

Forwarding.

Pine


-- Forwarded message --
From: Léa Lacroix 
Date: Wed, Mar 29, 2017 at 4:34 AM
Subject: [Wikidata] Significant change: new data type for geoshapes
To: wikidata-t...@lists.wikimedia.org, "Discussion list for the Wikidata
project." , pywiki...@lists.wikimedia.org


Hello all,

We’ve been working on a new data type that allows you to link to the
*geographical
shapes* that are now stored on Commons. This data type will be deployed on
Wikidata on *April 17th*.

This data type refers to the geographical shapes that are enabled on
Wikimedia Commons since the beginning of this year. Here you can find more
information about this .

The property creators will be able to create properties with this geoshape
data type by selecting “Geographical shape” in the data type list.

When the property is created, you can use it in statements, and when
filling the value, if you start typing a string, you can choose the name of
a geoshape in the list of what exists on Commons.

[image: Screenshot test geoshape in Wikidata.png]



One thing to note: We currently do not export statements that use this
datatype to RDF. They can therefore not be queried in the Wikidata Query
Service. The reason is that we are still waiting for geoshapes to get
stable URIs. This is handled in this ticket
.

Before the deployment, you can test it on http://test.wikidata.org (see for
example the property “geotest” on Q22 ).
If you have any question, feel free to ask!

Cheers,

-- 
Léa Lacroix
Project Manager Community Communication for Wikidata

Wikimedia Deutschland e.V.
Tempelhofer Ufer 23-24
10963 Berlin
www.wikimedia.de

Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.

Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das Finanzamt für
Körperschaften I Berlin, Steuernummer 27/029/42207.

___
Wikidata mailing list
wikid...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Fwd: [Wiki-research-l] Research Scientist position at WMF

[Pine W]

Forwarding in case there are statisticians or scientists in OSM that would
be interested in this job posting.

Pine


-- Forwarded message --
Hi all,

The Research team at the Wikimedia Foundation has just opened a full-time
research scientist position
.
In the past years, the team has worked on a variety of projects, including:
building ML-based scoring systems for Wikipedia and Wikidata

, recommendations systems for article creation
,
models
to detect harassment and personal attacks
,
and more. we are looking to add one more full-time role to our team to
expand our research capacity and strengthen our collaborations with
academia and industry.

If this is the kind of job you're interested in, please consider applying.
If you know people in your network who may be a good fit, please encourage
them to apply.

Best,
Leila

--
Leila Zia
Senior Research Scientist
Wikimedia Foundation
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Fwd: [Analytics] February 15, 2017 Research Showcase

[Pine W]

The first presentation mentioned below may be of interest to OSM folks, as
well as Wikimedia maps people. These talks are presented by the Wikimedia
Foundation and are live-streamed.

Pine


-- Forwarded message --
From: Sarah R 
Date: Tue, Feb 14, 2017 at 2:49 PM
Subject: [Analytics] February 15, 2017 Research Showcase
To: wikimedi...@lists.wikimedia.org, analyt...@lists.wikimedia.org,
wiki-researc...@lists.wikimedia.org


Hi Everyone,

The next Research Showcase will be live-streamed this February 15, 2017 at
11:30 AM (PST) 18:30 UTC.

YouTube stream: https://www.youtube.com/watch?v=m6smzMppb-I

As usual, you can join the conversation on IRC at #wikimedia-research. And,
you can watch our past research showcases here
.

This month's presentations:

Wikipedia and the Urban-Rural DivideBy *Isaac Johnson*Wikipedia articles
about places, OpenStreetMap features, and other forms of peer-produced
content have become critical sources of geographic knowledge for humans and
intelligent technologies. We explore the effectiveness of the peer
production model across the rural/urban divide, a divide that has been
shown to be an important factor in many online social systems. We find that
in Wikipedia (as well as OpenStreetMap), peer-produced content about rural
areas is of systematically lower quality, less likely to have been produced
by contributors who focus on the local area, and more likely to have been
generated by automated software agents (i.e. “bots”). We continue to
explore and codify the systemic challenges inherent to characterizing rural
phenomena through peer production as well as discuss potential solutions.


Wikipedia Navigation VectorsBy *Ellery Wulczyn
*In this project, we
learned embeddings for Wikipedia articles and Wikidata
 items by applying
Word2vec  models to a corpus of
reading sessions. Although Word2vec models were developed to learn word
embeddings from a corpus of sentences, they can be applied to any kind of
sequential data. The learned embeddings have the property that items with
similar neighbors in the training corpus have similar representations (as
measured by the cosine similarity
, for example).
Consequently, applying Wor2vec to reading sessions results in article
embeddings, where articles that tend to be read in close succession have
similar representations. Since people usually generate sequences of
semantically related articles while reading, these embeddings also capture
semantic similarity between articles.

-- 
Sarah R. Rodlund
Senior Project Coordinator-Product & Technology, Wikimedia Foundation
srodl...@wikimedia.org

___
Analytics mailing list
analyt...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/analytics
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Fwd: Re: Beware Pokemon users

[Rod Bera]

 Forwarded Message 
Subject: Re: [OSM-talk] Beware Pokemon users
Date: Tue, 27 Dec 2016 00:40:18 +0100
From: Rod Bera 
To: Andy Mabbett 

Hi Andy,

I get what you mean,

and I acknowledge that though I consider OSM should be put first this is
not the case for everyone, and this is fine.

But here things are going one step further: it's about deliberately
putting non-existing features and/or mis-tagging features, which amounts
to vandalism.
A new kind of vandalism, as we could be overwhelmed by the number of
"users" doing it in various places for a coinciding purpose.
To me this is quite new.

I hope this won't happen.

And I won't comment your appreciation over "geographical practices".
Every one is welcome to practice geography their own way...
As long as we are talking about geography, i.e. depicting what is
(really is, not what Pokemon hunter wish were) on or around the surface
of Earth.

Regards,

Rod

On 26/12/16 13:19, Andy Mabbett wrote:
> On 26 December 2016 at 11:36, Rod Bera  wrote:
> 
>> Systematic bias put into the OSM base towards maximising benefits for a
>> minority of users is a threat.
>> Especially when the primary interest of these users is not OSM in itself.
> 
> Most edits to OSM benefit only a minority of users
> 
> Most editors of OSM - including me - do so because we have a primary
> interest which is not OSM itself.
> 
> Shall those of us who edit OSM because we have an interest in a
> locality, or a use-case, all stop editing, and leave OSM only to those
> for whom it is some form of geographical masturbation?
> 


-- 
Rod Béra,  MCF Géomatique/   Lecturer, Geomatics
   et SIG pour l'Environnement  /and Environmental GIS
Agrocampus-Ouest|65 r.Saint-Brieuc|CS84215|35042 Rennes cedex|France
+33 (0) 223 48 5553 - roderic.b...@agrocampus-ouest.fr

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

[OSM-talk] Fwd: [MediaWiki-l] Maps 4.0.0-RC1 released

[Pine W]

Forwarding in case some of the mapping experts on other mailing lists would
like to look at this.

Pine


-- Forwarded message --
From: Jeroen De Dauw 
Date: Thu, Nov 10, 2016 at 2:39 PM
Subject: [MediaWiki-l] Maps 4.0.0-RC1 released
To: MediaWiki announcements and site admin list <
mediawik...@lists.wikimedia.org>


Hey all,

I'm happy to announce the first release candidate for Maps 4.0. Maps is a
MediaWiki extension to work with and visualize geographical information.
Maps 4.0 is the first major release of the extension since January 2014,
and it brings a ton of "new" functionality. This release candidate is meant
to gather feedback and not suitable for usage in production. The 4.0
release itself will be made one week from now if no issues are found.

For an overview of what's new, see
https://www.entropywins.wtf/blog/2016/11/09/maps-4-0-0-rc1-released/

Cheers

--
Jeroen De Dauw | https://entropywins.wtf | https://keybase.io/jeroendedauw
Software craftsmanship advocate | Developer at Wikimedia Germany
~=[,,_,,]:3
___
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Fwd: [HOT] Geospatial devroom at FOSDEM 2017

[Pine W]

Forwarding.
-- Forwarded message --
From: "Margherita Di Leo" 
Date: Oct 25, 2016 02:01
Subject: [HOT] Geospatial devroom at FOSDEM 2017
To: "hot" 
Cc:

Call for Presentations

Please forward!

FOSDEM is a free and non-commercial event bringing together about 5000
developers in Brussels, Belgium. The goal is to provide open source
software developers and communities a place to meet and share thoughts. The
participation is free of charge, although donations are welcome. The next
edition will take place on 4 - 5 February 2017. For the third (!) time
there will be a Geospatial devroom and will be happening on Sunday 5/2/2017!

Geospatial technologies and mapping used to be specialist work, but
nowadays location and maps are becoming part of many projects/applications,
which usually use only a small subset of the possibilities the data and
software offer.

The geospatial devroom is the place to talk about open, geo-related data
and software and their ecosystem. This includes standards and tools, e.g.
for spatial databases, and online mapping, geospatial services, used for
collecting, storing, delivering, analysing, and visualizing purposes.

We welcome submissions about:

   -

   Web and desktop GIS applications;


   -

   Collaborative editing / versioning of geodata and metadata;
   -

   Interoperable geospatial web services and specifications;
   -

   Collection of data using sensors / UAVs / satellites;
   -

   Geo-analytic algorithms / libraries;
   -

   Geospatial extensions for classical databases (indexes, operations) and
   dedicated databases;
   -

   Big geodata, scalable GIS applications;
   -

   Volunteered Geographic information - Crowdsourced geodata.


HOW TO SUBMIT YOUR PROPOSAL FOR A TALK

Are you thrilled to present your work to other open source developers?
Would you like to run a discussion? Any other ideas?

Please submit your proposal at:

 https://fosdem.org/submit

Make sure to select the 'Geospatial devroom' as 'Track'. If you have an
account from previous years, you should be using the same.

Please specify in the notes if you prefer for your presentation either a
short timeslot (lightning talks ~10 minutes) or a long timeslot (20 minutes
presentation + discussion). However, note that time slots are indicative
and will be assigned according to the timing of the session.

The DEADLINE for submissions is Thursday **1st December 2016**.

Notification of acceptance will be sent to the Authors by 11/12/2016 at the
latest.

Should you have any questions, please do not hesitate to get in touch with
the organisers of the devroom at fosdem-geospatial at gisky.be!

Want to know what FOSDEM geospatial is like? Check out the videos and the
presentations of our previous two editions: [1,2]

The organizers

Johan Van de Wauw

Margherita Di Leo

Anne Ghisla

Martin Hammitzsch

[1] https://archive.fosdem.org/2015/schedule/track/geospatial/

[2] https://archive.fosdem.org/2016/schedule/track/geospatial/

-- 
Margherita Di Leo

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

[OSM-talk] Fwd: Re: Hurricane Matthew: Jérémie Post Event Imagery - from drone now available

[Jean-Guilhem Cailton]

Forwarding this to the talk mailing list, as the censors of the
h...@openstreetmap.org mailing list are still in action.


 Message transféré 
Sujet : Re: Hurricane Matthew: Jérémie Post Event Imagery - from drone
now available
Date :  Thu, 13 Oct 2016 09:18:05 +0200
De :Jean-Guilhem Cailton 
Pour :  Mike Thompson , HOT 



Hi,

The instructions for that project
(http://taches.francophonelibre.org/project/44) - "for very experienced
mappers" - asked to use "Bing as common geometrical reference (or other
imagery that was used for OSM mapping of these area)", as is generally
considered good practice in OSM mapping - unless you have good reasons
to know that you have a better reference (and also time to adjust
geometries).

Note that there is now a project to map damage from UAV 5 cm imagery, of
interest to the Government of Haiti who sent Fred there to fly Potentiel
3.0 (http://potentiel3-0.org) drones :
http://taches.francophonelibre.org/project/63

Best wishes,

Jean-Guilhem


Le 13/10/2016 à 05:06, Mike Thompson a écrit :
> To complicate matters, it seems that some of the mapping on this
> project was done under a project on some other tasking manager using a
> different imagery source
> (tms[23]:http://imagery.openstreetmap.fr/tms/1.0.0/haiti_pleiades_201610/{zoom}/{x}/{y}
> )
> which does not align with either Bing or the imagery for this project
> (tms[22]:http://oam-tiles.s3.amazonaws.com/9ac2a651-43b7-4e46-b4c9-c7aa013a289c/{zoom}/{x}/{y}.png
> ).
>
> On Wed, Oct 12, 2016 at 8:48 PM, Mike Thompson  > wrote:
>
> Suggest the instructions for this and similar tasks explicitly
> state that existing mapping is to be realigned to new imagery (if
> that is in fact what is desired).  The instructions imply this
> when they say "...but all final mapping and validation should use
> this imagery for validation." 
>
>
>
>
> ___
> HOT mailing list
> h...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/hot


-- 
"Tant qu’on n’aura pas compris que le cerveau est une machine à dominer,
on ne pourra pas lutter efficacement contre ces hiérarchies aliénantes."
Dominique Dupagne, La revanche du rameur

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

[OSM-talk] Fwd: Invitation: OSM Analytics Roadmap Chat

[Cristiano Giovando]

Hey fellow mappers,

Some of you already know and have been using OSM Analytics since its
launch in April [0], but for those who are not familiar with it,
here's the direct link http://osm-analytics.org

This was initially a small prototype project, but given the interest
and feedback by many in the OSM community, we're now thinking how to
scale it and include more functionalities.

To start the discussion around a roadmap, we are holding a public
community chat this Thursday, August 18th, at 17:00UTC [1] on Gitter:
https://gitter.im/hotosm/osm-analytics

Everyone is welcome to join - I think we will have some more technical
discussions on the infrastructure design, but also less technical ones
about feature requests and ideas for new functions.

All OSMA code is public here [2]. Would be great to also discuss how
to integrate other OSM applications that focus on statistics, quality
assurance, user analytics and validation into OSMA and vice-versa. One
example is this work [3] by Jennings Anderson, built on a similar
processing workflow/stack, that has lots of great insights and
visualizations on OSM contributors and data quality.

If you are around on Thursday, we'd love you to join and share your
ideas. See you then!

Cristiano


[0] 
https://hotosm.org/updates/2016-04-28_explore_how_the_world_is_mapped_with_osm_analytics

[1] 
http://www.timeanddate.com/worldclock/fixedtime.html?msg=OSM+Analytics+Roadmap+Chat&iso=20160818T17&p1=1440&ah=1

[2] https://github.com/hotosm/osm-analytics

[3] http://mapbox.github.io/osm-analysis-collab/osm-quality.html


-- 
Cristiano Giovando
Humanitarian OpenStreetMap Team
cristiano.giova...@hotosm.org
http://www.hotosm.org

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

[OSM-talk] Fwd: [HOT] MapSwipe Launched!

[Heather Leson]

Hi!

MapSwipe is launched today.  I like to think of it as a pre-processing
imagery tool to curate a cleaner dataset for mappers. Imagine less blank,
blurry images, or "nothing to map" tiles. This tool aims to have people
microtask the tiles in a game way. We will start with Missing Maps projects
and then we hope to make it more available as we iterate. (the code is on
github)

http://mapswipe.org/


Mapswipe is an MSF sponsored mobile app supporting projects to go on
OpenStreetMap.

More details below.

Heather


Heather Leson
heatherle...@gmail.com
Twitter/skype: HeatherLeson
Blog: textontechs.com

-- Forwarded message --
From: Pete Masters 
Date: Fri, Jul 15, 2016 at 3:49 PM
Subject: [HOT] MapSwipe Launched!
To: "h...@openstreetmap.org" 


Hi all, as promised, MapSwipe is now available on App Store, Play Store and
via http://mapswipe.org/

There's a blog post on it, here:
http://www.missingmaps.org/blog/2016/07/14/mapswipe/

Would love it if you'd give it a go and, assuming you like it (!), give us
a hand sharing it

Lot's of stuff to come, but the app is ready for mapping. At the moment,
these are just Missing Maps projects, but once we are on our feet, we hope
to open it right up. Data exporter also on its way, soon!

If you have any problems, encounter bugs or have comments, please feel free
to let us know at http://bit.ly/MapSwipeFBack We expect some bugs, of
course, and your help pointing them out to us would be much appreciated...


Cheers,

Pete

-- 
*Pete Masters*
Missing Maps Project Coordinator
+44 7921 781 518

missingmaps.org 

*@pedrito1414* 
*@theMissingMaps* 
*facebook.com/MissingMapsProject*


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

Re: [OSM-talk] Fwd: Automated edits code of conduct

[Warin]

On 7/11/2016 11:45 PM, Martin Koppenhoefer wrote:


sent from a phone


Il giorno 11 lug 2016, alle ore 14:01, Éric Gillet  
ha scritto:

I agree that survey are that on-premise survey is the best review method. But 
then you are adressing armchair mapping as a whole and not specifically 
search-and-replace edits.


yes, armchair mapping generally bears the risk of misinterpreting the actual 
situation, (depending on what kind of tags you use this can be more or less 
important).
Doing it in search and replace fashion is slightly different though, as you 
risk falsifying  information someone else has meticulously surveyed (assuming 
that armchair mapping is mostly about the addition of new stuff).


Not necessarily. For example;

Search sport=football

Replace with sport=soccer, rugby or whatever is seen there by satellite imagery

OR

Search sport=multi

Add sport=soccer;multi or sport=tennis;multi or whatever is seen with satellite 
imagery.

As each change/addition is manually sighted armchair fashion and adds better 
detail I see this as an improvement over what was originally tagged.
I also view it as not a mechanical edit as each feature must be 'looked at' 
(admittedly using satellite imagery) individually.






There are instances where a survey is not necessary, and the information needed 
to perform the modification is available on imagery, website or open data, so 
the need to be on the premises is limited. But again this does apply to all 
armchair mapping.


yes (let's say a survey is less necessary, still there is always the 
possibility something has changed in the meantime and any edit will make it 
appear as if the feature still existed at the time of the survey)

cheers,
Martin
___
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] Fwd: Automated edits code of conduct

[john whelan]

>yes, armchair mapping generally bears the risk of misinterpreting the
actual situation, (depending on what kind of tags you use this can be more
or less important).
Doing it in search and replace fashion is slightly different though, as you
risk falsifying  information someone else has meticulously surveyed
(assuming that armchair mapping is mostly about the addition of new stuff).

and then you get the situation in Africa with HOT, new mappers less than 24
hours old, marking a tile done in HOT using tags which have extremely low
usage in taginfo and are not the recommended tags for the project or area.
It is tempting to do a search and replace for highway=pedestrian on the
mapper and replace it with highway=path the recommended value in the
African Highway wiki.  http://wiki.openstreetmap.org/wiki/Highway_Tag_Africa

I agree mapping done on the ground by locals is best.

Cheerio John

On 11 July 2016 at 09:45, Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> > Il giorno 11 lug 2016, alle ore 14:01, Éric Gillet <
> gill3t.3ric+...@gmail.com> ha scritto:
> >
> > I agree that survey are that on-premise survey is the best review
> method. But then you are adressing armchair mapping as a whole and not
> specifically search-and-replace edits.
>
>
> yes, armchair mapping generally bears the risk of misinterpreting the
> actual situation, (depending on what kind of tags you use this can be more
> or less important).
> Doing it in search and replace fashion is slightly different though, as
> you risk falsifying  information someone else has meticulously surveyed
> (assuming that armchair mapping is mostly about the addition of new stuff).
>
>
>
> >
> > There are instances where a survey is not necessary, and the information
> needed to perform the modification is available on imagery, website or open
> data, so the need to be on the premises is limited. But again this does
> apply to all armchair mapping.
>
>
> yes (let's say a survey is less necessary, still there is always the
> possibility something has changed in the meantime and any edit will make it
> appear as if the feature still existed at the time of the survey)
>
> cheers,
> Martin
> ___
> 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] Fwd: Automated edits code of conduct

[Martin Koppenhoefer]

sent from a phone

> Il giorno 11 lug 2016, alle ore 14:01, Éric Gillet 
>  ha scritto:
> 
> I agree that survey are that on-premise survey is the best review method. But 
> then you are adressing armchair mapping as a whole and not specifically 
> search-and-replace edits.


yes, armchair mapping generally bears the risk of misinterpreting the actual 
situation, (depending on what kind of tags you use this can be more or less 
important).
Doing it in search and replace fashion is slightly different though, as you 
risk falsifying  information someone else has meticulously surveyed (assuming 
that armchair mapping is mostly about the addition of new stuff).



> 
> There are instances where a survey is not necessary, and the information 
> needed to perform the modification is available on imagery, website or open 
> data, so the need to be on the premises is limited. But again this does apply 
> to all armchair mapping.


yes (let's say a survey is less necessary, still there is always the 
possibility something has changed in the meantime and any edit will make it 
appear as if the feature still existed at the time of the survey)

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

Re: [OSM-talk] Fwd: Automated edits code of conduct

[Éric Gillet]

2016-07-11 2:16 GMT+02:00 Frederik Ramm :

> On 07/11/2016 02:02 AM, Éric Gillet wrote:
> > If you do a search-and-replace on 20 elements and review manually the
> > change, it is covered under the AE CoC.
>
> No, the document clearly states in the "Scope" section:
>
> "use of find-and-replace functionality using a standard editor such as
> JOSM or finding using services such as Overpass API and changing without
> reviewing cases individually;"
>
> Sadly, we often have people who run search-and-replace operations and
> *claim* that they have "reviewed cases individually", and then if you
> look at their edit, they have changed a tag on a POI that sits in the
> middle of a road or so - which means that they were either lying, or
> they have only done a very, very cursory "manual review" of their change.
>
> An automated, or mechanical, edit is when you do not look at the
> individual object you're editing.
>

When you add or correct some information on features are you responsible
for the data outside the original reach of the changeset ? If so, it's a
really important point for all contributions. I agree that ideally you
would review all the data, but sometimes it is not necessary or even
possible when you are not local.

I believe that changesets should try to be atomical, so when the point of
the changeset is to correct phone numbers for examples, you shouldn't touch
other tags.
In the case that the main subject of the changeset cause controversy, and
must be reversed, you wouldn't want to remove other unrelated changes (e.g.
node positions when editing phone numbers)

There is no similar policy covering manual edits. But of course if
> someone *manually* changes 500 landuse=wood to landuse=forest across the
> planet, it is still possible that they make a mistake and it needs
> fixing in some way, or if they do it repeatedly and cause problems with
> it, they might still be blocked. [...] However, causing trouble through
> manual edits is so much less
> frequent than causing trouble with mechanical edits that we have written
> up a policy on the latter.
>

Limiting the automation doesn't necessarily reduce the raw number of
errors. What it does is that in case of an mapper/software error, the error
may be applied to less content than a large edit.
But contributors can put a lot more focus and time in the "automated" edit
than on each one-by-one manual updates, so I don't think the net gain of
"automated" edits is negative.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Fwd: Automated edits code of conduct

[Éric Gillet]

2016-07-11 11:28 GMT+02:00 Martin Koppenhoefer :

>
> 2016-07-11 2:02 GMT+02:00 Éric Gillet :
>
>> If you do a search-and-replace on 20 elements and review manually the
>> change, it is covered under the AE CoC. I don't think of that as an
>> advanced or uncommon task.
>
>
>
> when you do any "search and replace" based edits I believe these are
> correctly considered automated edits, because you can only in rare
> occassions do a real "manual review": you would have to visit (or at least
> have visited) all those places and see what is there on the ground,
> otherwise you can't be sure what the tags are applied to, and if a change
> makes sense.
>

I agree that survey are that on-premise survey is the best review method.
But then you are adressing armchair mapping as a whole and not specifically
search-and-replace edits.

There are instances where a survey is not necessary, and the information
needed to perform the modification is available on imagery, website or open
data, so the need to be on the premises is limited. But again this does
apply to all armchair mapping.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Fwd: Automated edits code of conduct

[Martin Koppenhoefer]

2016-07-11 2:02 GMT+02:00 Éric Gillet :

> If you do a search-and-replace on 20 elements and review manually the
> change, it is covered under the AE CoC. I don't think of that as an
> advanced or uncommon task.



when you do any "search and replace" based edits I believe these are
correctly considered automated edits, because you can only in rare
occassions do a real "manual review": you would have to visit (or at least
have visited) all those places and see what is there on the ground,
otherwise you can't be sure what the tags are applied to, and if a change
makes sense.

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

Re: [OSM-talk] Fwd: Automated edits code of conduct

[Frederik Ramm]

Hi,

On 07/11/2016 02:02 AM, Éric Gillet wrote:
> If you do a search-and-replace on 20 elements and review manually the
> change, it is covered under the AE CoC.

No, the document clearly states in the "Scope" section:

"use of find-and-replace functionality using a standard editor such as
JOSM or finding using services such as Overpass API and changing without
reviewing cases individually;"

Sadly, we often have people who run search-and-replace operations and
*claim* that they have "reviewed cases individually", and then if you
look at their edit, they have changed a tag on a POI that sits in the
middle of a road or so - which means that they were either lying, or
they have only done a very, very cursory "manual review" of their change.

An automated, or mechanical, edit is when you do not look at the
individual object you're editing.

There is no similar policy covering manual edits. But of course if
someone *manually* changes 500 landuse=wood to landuse=forest across the
planet, it is still possible that they make a mistake and it needs
fixing in some way, or if they do it repeatedly and cause problems with
it, they might still be blocked. This is not a court system; DWG doesn't
need a law on the Wiki to take action against someone who causes
trouble. However, causing trouble through manual edits is so much less
frequent than causing trouble with mechanical edits that we have written
up a policy on the latter.

Bye
Frederik

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

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

[OSM-talk] Fwd: Automated edits code of conduct

[Éric Gillet]

2016-07-10 23:56 GMT+02:00 Christoph Hormann :

> On Sunday 10 July 2016, Éric Gillet wrote:
> >
> > In contrary to the Contributor Terms, these rules :
> >
> >- Are not shown to new contributors
> >- Are not accepted by new or existing contributors
>
> Maybe that is because they don't apply to the vast majority of
> contributors.  You don't need to accept the automated edit rules to
> contribute to OSM as long as you don't do automated edits.
>

If you do a search-and-replace on 20 elements and review manually the
change, it is covered under the AE CoC. I don't think of that as an
advanced or uncommon task.


>
> >- Doesn't seem to have been voted on before their "establishment"
> >- Seems to have been written by an eminent, but small set of
> >contributors (history
>
> Doesn't this also apply for the Contributor Terms?
>

Yes, it does. But it's mainly the combination of these points that is
problematic.

>
> Remember OSM is largely a do-ocracy - those who put work into developing
> the rules have a significant influence on their content.


It shouldn't forbid to re-evaluate them.

This does not
> make them illegitimate.


This doesn't make them legitimate either.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Fwd: HOT Summit: September 22 in Brussels, Belgium

[Tyler Radford]

Friends & colleagues in the global OSM community -- if you're attending or
were thinking of attending SoTM in Brussels, I invite you to join us one
day earlier for the HOT Summit http://summit.hotosm.org/

Discounts available for students and OSM community leaders who register
early (over the next month).
Tyler

-- Forwarded message --
From: Tyler Radford 
Date: Wed, May 18, 2016 at 10:50 AM
Subject: HOT Summit: September 22 in Brussels, Belgium
To: hot 


Were you thinking about attending State of the Map in Brussels this
September? Here's another great reason to participate:

The second annual *HOT Summit* is back this year and will take place one
day before State of the Map - on September 22, 2016.

Early registration discounts are available for the next month at
https://summit.hotosm.org

*Note:* *These are two separate events and you must register separately for
each. For State of the Map: Submit your talk/scholarship app by this
Saturday May 21.*
*For the HOT Summit: Information on talks and the program forthcoming.*

*Tyler Radford*
Executive Director
tyler.radf...@hotosm.org
@TylerSRadford

*Humanitarian OpenStreetMap Team*
*Using OpenStreetMap for Humanitarian Response & Economic Development*
web  | twitter  | facebook
 | donate 
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Fwd: Biggest Wikimedia Commons photos dataset in Italy - Paolo Monti (BEIC)

[Federico Leva (Nemo)]

Forwarding on request.

Photos are not geotagged yet, but Paolo Monti shot many of them as part 
as geographic surveys hence I expect many will be valuable depictions of 
some rare corners of the OSM map.


Soon we should have a list of (approximate) places (categories) in one 
of the Commons pages linked below.


Nemo-BEIC

  Messaggio inoltrato 
Oggetto: [cultural-partners] Biggest donation of photos in Italy - Paolo 
Monti (BEIC)

Data: Fri, 8 Apr 2016 16:26:20 +0200
Mittente: marcok

Hi to all,
I’m the Wikipedian in residence at the digital library of Fondazione 
BEIC, Milan, Italy.


In the last days we at BEIC are uploading almost the entire photo 
archive of a notable Italian photographer, Paolo Monti, counting 15.000 
images.

The whole archive was acquired by Fondazione BEIC in 2008.

https://commons.wikimedia.org/wiki/Category:Photographs_by_Paolo_Monti

For what I know, this is the biggest donation of images in one shot ever 
made in Italy. It’s also the first time that a digital archive from a 
famous photographer is almost completely uploaded into Commons.


This notable result was possible thanks to the long-lasting 
collaboration between BEIC and Wikimedia Italia, started in 2014, and 
also thanks to the technical assistance of Federico Leva aka Nemo, the 
previous WiR at BEIC, now GLAM specialist at Wikimedia Italia.


The photos of the Paolo Monti archive represent a variety of subjects 
(art, events, architecture, people, portraits, nature, artistic nudes, 
experimental) and were shot since 1950s to 1980s. Many of them are B/W, 
but there are also many fascinating colourful artistic/experimental 
pictures.


We are now beginning to work on:
 * fixing categories (often translating the basic original italian 
keywords into english Commons categories) and providing a more detailed 
categorization
 * inserting useful images into Wikipedia articles (in italian, english 
and other languages)
 * selecting the best photos to candidate them as "featured pictures” 
in Wikimedia Commons (only those with 2 Megapixel or more).


Please help us, this is a huge work!
If you have any other ideas on how the images may be used, let us know!

Thank you,

Marco Chemello
Wikipedian in residence, Fondazione BEIC, Milan
(also Wikipedian in residence at the Science Museum, Milan)

See:
http://www.beic.it/en/articles/digital-library
https://commons.wikimedia.org/wiki/Commons:BEIC
https://it.wikipedia.org/wiki/Progetto:GLAM/BEIC (main project page)
https://en.wikipedia.org/wiki/Wikipedia:GLAM/BEIC
http://www.beic.it/en/node/1969 (Fondo Paolo Monti - in Italian)


___
Cultural-Partners mailing list
cultural-partn...@wikimedia.ch
https://intern.wikimedia.ch/lists/listinfo/cultural-partners
Please treat emails sent to this list as confidential.Ask senders for 
permission before forwarding emails off-list.



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