[Talk-it] R: [talk-it] Falsi guadi

[canfe]

Ciao Volker,

li segnala anche OSMOSE.
Solo che in pianura qualche immagine la trovi e puoi stabilire che c’è un ponte 
(di solito è così), in montagna… bisogna andarci per sapere se è intubato o se 
è un guado davvero.
So cosa fare quest’estate… J

 

saluti da Ferruccio

 

Da: Volker Schmidt [mailto:vosc...@gmail.com] 
Inviato: giovedì 21 marzo 2019 18:51
A: openstreetmap list - italiano
Oggetto: [Talk-it] [talk-it] Falsi guadi

 

Per caso mi sono imbattuto (e sono sicuro che non sono il primo) nel problema 
dei "passaggi a livello" di highway e waterway.

Ci ne sono sicuramente decine di migliaia solo in Italia.

Cercate con keepright.at:

> intersections without junctions > highway.- waterway

 

Buon divertimento

 

Volker

 

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

Re: [Talk-us] Proposed mechanical edit - remove is_in:continent in USA

[Shawn K. Quinn]

On 3/20/19 02:03, Mateusz Konieczny wrote:
> is_in:continent=* is subjective as both division Earth landmass into
> continents[1] and boundaries between continents[2] are mostly
> subjective. There are many competing ways to split world into continents
> and OSM is not proper place to record all of them or one selected system.
> 
> In rare cases where one desires to assign locations to continents it can
> be done using location data inherently included in OSM objects and
> explicit tags added to part of objects are not really useful anyway.
> 
> is_in:continent tag should be removed to avoid confusing newbies and
> discourage adding new instances of this undesirable tag.
> 
> I propose to run an automated edit restricted to USA that will remove
> all instances of this tag.
[...]

I'm in favor; good riddance. (Cue "Ding Dong The Witch Is Dead")

-- 
Shawn K. Quinn 
http://www.rantroulette.com
http://www.skqrecordquest.com

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

Re: [talk-au] [OSGeo Oceania] OSGeo Oceania as a not-for-profit entity? Your feedback, please

[Phil Wyatt]

Might be back here John although I cant see anything specific

 

https://lists.osgeo.org/pipermail/aust-nz/2018-August/thread.html#1932 

 

From: John Bryant [mailto:johnwbry...@gmail.com] 
Sent: Friday, 22 March 2019 2:36 PM
To: Bruce Bannerman
Cc: australian-qgis-user-gr...@googlegroups.com; 
pacific-isla...@lists.osgeo.org; foss4g-oceania; talk-nz; 
ocea...@lists.osgeo.org; OSM Australian Talk List
Subject: Re: [talk-au] [OSGeo Oceania] OSGeo Oceania as a not-for-profit 
entity? Your feedback, please

 

Hi Bruce, we're hoping to wrap up this comment period on the 29th, it would be 
good to take your comments into account before we embark on a course of action 
if possible.

 

Can you be a bit more specific about which email you're referring to (or does 
someone else perhaps know)? Alternatively are you able to provide a summary 
here?

 

In any case, we will of course always be open to discussion on the direction of 
this organisation!

 

Cheers

John

 

On Tue, 19 Mar 2019 at 18:13, Bruce Bannerman  
wrote:

Hi John,

 

I’m currently travelling through Outback Australia with severely limited 
Internet access.

 

I intend making comments, but will not be able to do so until early April, 
after I return.

 

For starters, see my earlier email on liability on the AustNZ list several 
months ago.

 

Kind regards,

 

Bruce


On 18 Mar 2019, at 19:31, John Bryant  wrote:

Hi all,

 

As promised, following on the heels of the successful FOSS4G SotM Oceania 
conference   in November 2018, we have embarked on 
a journey to lay down a strong foundation for the growth of this community. In 
addition to planning a new instance of the conference in Wellington, New 
Zealand, for November 2019, we are also doing significant ground work on 
establishing a not-for-profit that can manage funds, enter into agreements, and 
act as a local chapter of OSGeo and OSMF.

 

We have developed a recommendation for an initial path forward, and we'd like 
you, the community, to provide your feedback. If you have experience or 
knowledge here, and can provide insight, or wish to contribute your thoughts, 
please chime in. Your comments are most welcome, and can be provided by 
responding to this email, or by commenting in the Google Doc.

 

The draft recommendation is attached as a PDF, and a live Google Doc version is 
linked here 

 . We will take input until the end of next week (29 March). At that point, 
we'll make adjustments where warranted, and hopefully be in a position to raise 
a motion to the OSGeo Oceania board to accept the recommendation, and begin the 
process.

 

If this is all new to you, and you're wondering what the heck OSGeo Oceania 
even is, please check out this basic wiki page 
  that will give you a bit of background. 
We'll be fleshing this out in the coming months, but I hope it gives you enough 
of an idea. We will certainly be aiming to increase our outreach, and get 
people involved from across the region.

 

Any questions, please ask!

 

Cheers

John Bryant

on behalf of OSGeo Oceania



___
Oceania mailing list
ocea...@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/oceania

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

[talk-au] OSGeo/OSM talk accepted at C3DIS

[adam steer]

hey folks

I pitched a talk about the growing OSGeo Oceania community at the C3DIS
conference (http://www.c3dis.com) and it was accepted as an oral
presentation.

Why? C3DIS is all about computational and data intensive science - and much
of that relies on the geospatial tools and data this community builds and
maintains. So it’s a bit of a PR / community building exercise; and timing
is a couple weeks ahead of the scheduled call for 2019 FOSS4G SotM Oceania
papers. it’s also introducing our new organisation - so some timing is a
bit ambitious.

Title and abstract below, I’ll build a revealJS-based talk here:
https://github.com/adamsteer/c3dis2019 - so please feel free to dump
relevant thoughts as issues; and help shape the conversation we want to
have with the ‘big science computers’ community.

Cheers

Adam

---

Title: The open geospatial community in Oceania

Abstract:
The Open Geospatial Foundation (OSgeo) and the Open Streetmap Foundation
(OSMF) have been mainstays in support of; and advocacy for; open geospatial
software and data for many years.

OSGeo supports foundational geospatial tooling used across the eResearch
community - from invisible infrastructure (GDAL; Proj4; pyWPS; Zoo-WPS ) to
prominent user-focussed, user facing applications (QGIS, geonode,
geoserver, geonetwork, leafletJS; openlayers) - to name just a few.

In 2009, an international conference of the OSGeo foundation was held in
Sydney; and after a long hiatus, the community was revived in 2018. The
result was a sold-out joint conference of the OSGeo and OSMF communities
for the Oceania region in Melbourne. This was both an incredible show of
community support, and an incredible showcase of open source innovation in
the region.

…and the momentum continues. By the time C3DIS happens, there will be a
fully-fledged local OSGeo Oceania organisation, aimed at supporting a
regional community of open source geo-developers, geo-users, and
geo-enablers - and 2019 conference organisation will be in full swing.

This talk will be about charting the journey of OSGeo Oceania so far, and
how the eResearch community in Australia and Oceania can engage with,
support, and benefit from this local and global community.

Come and join the party!


-- 
Dr. Adam Steer
http://spatialised.net
https://www.researchgate.net/profile/Adam_Steer
http://au.linkedin.com/in/adamsteer
http://orcid.org/-0003-0046-7236
+61 427 091 712
skype: adam.d.steer
tweet: @adamdsteer
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] [OSGeo Oceania] OSGeo Oceania as a not-for-profit entity? Your feedback, please

[John Bryant]

Hi Bruce, we're hoping to wrap up this comment period on the 29th, it would
be good to take your comments into account before we embark on a course of
action if possible.

Can you be a bit more specific about which email you're referring to (or
does someone else perhaps know)? Alternatively are you able to provide a
summary here?

In any case, we will of course always be open to discussion on the
direction of this organisation!

Cheers
John

On Tue, 19 Mar 2019 at 18:13, Bruce Bannerman <
bruce.bannerman.os...@gmail.com> wrote:

> Hi John,
>
> I’m currently travelling through Outback Australia with severely limited
> Internet access.
>
> I intend making comments, but will not be able to do so until early April,
> after I return.
>
> For starters, see my earlier email on liability on the AustNZ list several
> months ago.
>
> Kind regards,
>
> Bruce
>
> On 18 Mar 2019, at 19:31, John Bryant  wrote:
>
> Hi all,
>
> As promised, following on the heels of the successful FOSS4G SotM Oceania
> conference  in November 2018, we have
> embarked on a journey to lay down a strong foundation for the growth of
> this community. In addition to planning a new instance of the conference in
> Wellington, New Zealand, for November 2019, we are also doing significant
> ground work on establishing a not-for-profit that can manage funds, enter
> into agreements, and act as a local chapter of OSGeo and OSMF.
>
> We have developed a recommendation for an initial path forward, and we'd
> like you, the community, to provide your feedback. If you have experience
> or knowledge here, and can provide insight, or wish to contribute your
> thoughts, please chime in. Your comments are most welcome, and can be
> provided by responding to this email, or by commenting in the Google Doc.
>
> The draft recommendation is attached as a PDF, and a live Google Doc
> version is linked here
> .
> We will take input until the end of next week (29 March). At that point,
> we'll make adjustments where warranted, and hopefully be in a position to
> raise a motion to the OSGeo Oceania board to accept the recommendation, and
> begin the process.
>
> If this is all new to you, and you're wondering what the heck OSGeo
> Oceania even is, please check out this basic wiki page
>  that will give you a bit of
> background. We'll be fleshing this out in the coming months, but I hope it
> gives you enough of an idea. We will certainly be aiming to increase our
> outreach, and get people involved from across the region.
>
> Any questions, please ask!
>
> Cheers
> John Bryant
> on behalf of OSGeo Oceania
>
> 
>
> ___
> Oceania mailing list
> ocea...@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/oceania
>
>
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Platform names

[Warin]

On 22/03/19 10:37, Ewen Hill wrote:
Re vision impaired users. Is this where 
https://wiki.openstreetmap.org/wiki/Tag:railway%3Dplatform_edge could 
be useful and whilst there is no route,  ot may assist... or hinder as 
it may not be rendered.


They do have those ripple strips/buttons that you can sense under your 
feet..
Arr OSM tactile_paving=* 
https://wiki.openstreetmap.org/wiki/Key:tactile_paving




On Fri, 22 Mar 2019, 9:43 AM Warin <61sundow...@gmail.com 
> wrote:


On 21/03/19 22:30, Sebastian S. wrote:

If you believe Wikipedia
http://en.wikipedia.org/wiki/Central_railway_station%2C_Sydney
The stations name is 'Central railway station' but it goes by
many colloquial names.

I don't like the way the platforms are named currently. "Platform
8+9 (8;9)" is surely not the name on the signboards. 


Depends on what 'sign board' you look at as to the platform
presentation.
The electronic sign boards at the station entry show a single
platform number, along with when the train leaves and the stops.

The fixed platform entry signs show the pair of platforms that the
entry accesses.

Some of the Australian platforms are split, some are paired. I
prefer split myself. But I am not making it a task for myself.


I am in favour of splitting the platforms to have each number
just called "Platform $". Maybe you can also indicated on which
side 8 and 9 is in relation to a path which you would walk into
the platform.


If the platforms are split that should give the user the required
indication.


Maybe name:left=Platform 8 makes sense?


Left and right depend on what direction you approach the
platforms, at Central you can approach lots of the platform pairs
from ether direction.


Another question I have is how would you route a blind person to
and onto the platform when there is no way?
What about segment indicators. I have not been to central station
but I assume for long trains there are segment indicators along
the platform for passengers to find they carriages quicker. Are
you planning to mapping these?


I have no plans to map these. I don't know if there is a defined
way to map them. Do you ? If so you might give a link for those
interested.

Have you looked at other train station in OSM?
I suggest to have a look at
Hamburg

https://www.openstreetmap.org/?mlat=53.552778=10.006389=15#map=18/53.55274/10.00677
Or Cologne https://www.openstreetmap.org/#map=18/50.94319/6.95853
Or Paris Gare du Nord
https://www.openstreetmap.org/#map=17/48.88156/2.35623
Or London Kings Cross
https://www.openstreetmap.org/#map=18/51.53194/-0.12326
Regards Sebastian
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.


On 21 March 2019 11:26:39 am AEDT, Thomas Manson
 
wrote:

Looking at Central Station, Sydney, the platform names are
things like 'Platform 4+5'.
(https://www.openstreetmap.org/relation/6015392)


From my reading of
https://wiki.openstreetmap.org/wiki/Tag%3Apublic_transport%3Dplatform,
this should be
the name of the station , so in this case that would be
either Central or Central Station, with the platform numbers
as the ref tag (which is already populated).

1) First of all, is my understanding correct? It should be
the station name.
2) Secondly, should the name be Central or Central Station
(assuming 1 is correct)?

Regards,
Thomas



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

Re: [talk-au] Platform names

[Ewen Hill]

Re vision impaired users. Is this where
https://wiki.openstreetmap.org/wiki/Tag:railway%3Dplatform_edge could be
useful and whilst there is no route,  ot may assist... or hinder as it may
not be rendered.

On Fri, 22 Mar 2019, 9:43 AM Warin <61sundow...@gmail.com> wrote:

> On 21/03/19 22:30, Sebastian S. wrote:
>
> If you believe Wikipedia
> http://en.wikipedia.org/wiki/Central_railway_station%2C_Sydney
> The stations name is 'Central railway station' but it goes by many
> colloquial names.
>
> I don't like the way the platforms are named currently. "Platform 8+9
> (8;9)" is surely not the name on the signboards.
>
>
> Depends on what 'sign board' you look at as to the platform presentation.
> The electronic sign boards at the station entry show a single platform
> number, along with when the train leaves and the stops.
>
> The fixed platform entry signs show the pair of platforms that the entry
> accesses.
>
> Some of the Australian platforms are split, some are paired. I prefer
> split myself. But I am not making it a task for myself.
>
> I am in favour of splitting the platforms to have each number just called
> "Platform $". Maybe you can also indicated on which side 8 and 9 is in
> relation to a path which you would walk into the platform.
>
>
> If the platforms are split that should give the user the required
> indication.
>
>
> Maybe name:left=Platform 8 makes sense?
>
>
> Left and right depend on what direction you approach the platforms, at
> Central you can approach lots of the platform pairs from ether direction.
>
> Another question I have is how would you route a blind person to and onto
> the platform when there is no way?
> What about segment indicators. I have not been to central station but I
> assume for long trains there are segment indicators along the platform for
> passengers to find they carriages quicker. Are you planning to mapping
> these?
>
>
> I have no plans to map these. I don't know if there is a defined way to
> map them. Do you ? If so you might give a link for those interested.
>
> Have you looked at other train station in OSM?
> I suggest to have a look at
> Hamburg
> https://www.openstreetmap.org/?mlat=53.552778=10.006389=15#map=18/53.55274/10.00677
> Or Cologne https://www.openstreetmap.org/#map=18/50.94319/6.95853
> Or Paris Gare du Nord
> https://www.openstreetmap.org/#map=17/48.88156/2.35623
> Or London Kings Cross
> https://www.openstreetmap.org/#map=18/51.53194/-0.12326
> Regards Sebastian
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>
> On 21 March 2019 11:26:39 am AEDT, Thomas Manson
>   wrote:
>>
>> Looking at Central Station, Sydney, the platform names are things like
>> 'Platform 4+5'. (https://www.openstreetmap.org/relation/6015392)
>>
>>
>> From my reading of
>> https://wiki.openstreetmap.org/wiki/Tag%3Apublic_transport%3Dplatform,
>> this should be
>> the name of the station , so in this case that would be either Central or
>> Central Station, with the platform numbers as the ref tag (which is already
>> populated).
>>
>> 1) First of all, is my understanding correct? It should be the station
>> name.
>> 2) Secondly, should the name be Central or Central Station (assuming 1 is
>> correct)?
>>
>> Regards,
>> Thomas
>>
>
>
> ___
> Talk-au mailing 
> listTalk-au@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-au
>
>
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au
>
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [Talk-GB] Milton Keynes Redways - How to Tag Consistently

[Warin]

On 22/03/19 02:35, Peter Neale via Talk-GB wrote:

Thanks to all for the helpful responses.

I have looked (again) at the OSM Tags for Routing at
https://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions#United_Kingdom
from which it is clear that foot=yes (for example) is implied by 
highway=cycleway.


However, Andy's question (if I understand it correctly) set me 
wondering whether there is any need to / benefit from distinguishing 
between foot=yes and foot=designated, etc.


MK council, in their public mapping, imply that Redways are NOT 
(generally / universally) PROW.  However, they DO seem to be 
"designated" for foot and cycle (and wheelchairs etc.), so perhaps 
they should be tagged; bicycle=designated; foot=designated,etc.,which 
highway=cycleway does not imply.


Also, at the end of my original post, I asked:

"*Naming*
I am not aware of any Redways that have unique names (someone will 
probably correct me on this), but I see several on OSM tagged with 
“name=Redway”.  Whilst I can see the attraction of doing this, I 
suspect that would not be considered good practice.  Should I delete 
that name, whenever I see it? "


Nobody seems to have commented on that yet (perhaps it got lost 
somewhere).  Any views?


I have transferred several 'names' to the description tag. Might be 
acceptable here?




Regards,

Peter

On Thursday, 21 March 2019, 13:54:20 GMT, Andy Townsend 
 wrote:



On 21/03/2019 13:35, Ed Loach wrote:
> How tagging changes over time...
>
> RichardF wrote:
>> highway=cycleway, segregated=no achieves all that in two tags
>> rather than
>> seven. :)
> I remember
> https://wiki.openstreetmap.org/wiki/Milton_Keynes_Mapping_Party_2009
> where it looks like we (or at least I) only used highway=cycleway, e.g.
> https://www.openstreetmap.org/way/34669428/history
>
If they have some legal status beyond being "mere shared cycleways"
would some sort of designation tag also make sense here? Currently
that's used for legal designations such as public footpaths, public
bridleways (and also I think core paths in Scotland).

Best Regards,

Andy




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

Re: [talk-au] Platform names

[Warin]

On 21/03/19 22:30, Sebastian S. wrote:
If you believe Wikipedia 
http://en.wikipedia.org/wiki/Central_railway_station%2C_Sydney
The stations name is 'Central railway station' but it goes by many 
colloquial names.


I don't like the way the platforms are named currently. "Platform 8+9 
(8;9)" is surely not the name on the signboards. 


Depends on what 'sign board' you look at as to the platform presentation.
The electronic sign boards at the station entry show a single platform 
number, along with when the train leaves and the stops.


The fixed platform entry signs show the pair of platforms that the entry 
accesses.


Some of the Australian platforms are split, some are paired. I prefer 
split myself. But I am not making it a task for myself.


I am in favour of splitting the platforms to have each number just 
called "Platform $". Maybe you can also indicated on which side 8 and 
9 is in relation to a path which you would walk into the platform.


If the platforms are split that should give the user the required 
indication.


Maybe name:left=Platform 8 makes sense?


Left and right depend on what direction you approach the platforms, at 
Central you can approach lots of the platform pairs from ether direction.


Another question I have is how would you route a blind person to and 
onto the platform when there is no way?
What about segment indicators. I have not been to central station but 
I assume for long trains there are segment indicators along the 
platform for passengers to find they carriages quicker. Are you 
planning to mapping these?


I have no plans to map these. I don't know if there is a defined way to 
map them. Do you ? If so you might give a link for those interested.

Have you looked at other train station in OSM?
I suggest to have a look at
Hamburg 
https://www.openstreetmap.org/?mlat=53.552778=10.006389=15#map=18/53.55274/10.00677

Or Cologne https://www.openstreetmap.org/#map=18/50.94319/6.95853
Or Paris Gare du Nord 
https://www.openstreetmap.org/#map=17/48.88156/2.35623
Or London Kings Cross 
https://www.openstreetmap.org/#map=18/51.53194/-0.12326

Regards Sebastian
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

On 21 March 2019 11:26:39 am AEDT, Thomas Manson 
 wrote:


Looking at Central Station, Sydney, the platform names are things
like 'Platform 4+5'. (https://www.openstreetmap.org/relation/6015392)


From my reading of
https://wiki.openstreetmap.org/wiki/Tag%3Apublic_transport%3Dplatform,
this should be
the name of the station , so in this case that would be either
Central or Central Station, with the platform numbers as the ref
tag (which is already populated).

1) First of all, is my understanding correct? It should be the
station name.
2) Secondly, should the name be Central or Central Station
(assuming 1 is correct)?

Regards,
Thomas



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



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

Re: [talk-cz] Dnes nefunkční overpass turbo

[Jan Macura]

No jo, pěkný :-)
Akorát na rozdíl od vypnuté WP se tohle do médií nedostalo..

H.

On Thu, 21 Mar 2019 at 14:40, majka  wrote:

> Viz přiložený obrázek, protest zhruba do devíti do večera. Na co já
> nemyslím, původně to ve mě evokovalo trochu jinou grafiku ;)
>
> [image: OT.png]
> ___
> talk-cz mailing list
> talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [talk-au] Platform names

[Thomas Manson]

Across those examples of stations, we see that there is no consistency 
regarding platform names - half have them as the station name, and the others 
as either Platform $, or just $.

I will split the platforms into 2 parts as that seems to be the preferred 
option, and leave the names as Platform $.

Regards,
Thomas

From: Sebastian S. 
Sent: 21 March 2019 22:30
To: talk-au@openstreetmap.org; Thomas Manson; talk-au@openstreetmap.org
Subject: Re: [talk-au] Platform names

If you believe Wikipedia 
http://en.wikipedia.org/wiki/Central_railway_station%2C_Sydney
The stations name is 'Central railway station' but it goes by many colloquial 
names.

I don't like the way the platforms are named currently. "Platform 8+9 (8;9)" is 
surely not the name on the signboards. I am in favour of splitting the 
platforms to have each number just called "Platform $". Maybe you can also 
indicated on which side 8 and 9 is in relation to a path which you would walk 
into the platform.

Maybe name:left=Platform 8 makes sense?

Another question I have is how would you route a blind person to and onto the 
platform when there is no way?
What about segment indicators. I have not been to central station but I assume 
for long trains there are segment indicators along the platform for passengers 
to find they carriages quicker. Are you planning to mapping these?
Have you looked at other train station in OSM?
I suggest to have a look at
Hamburg 
https://www.openstreetmap.org/?mlat=53.552778=10.006389=15#map=18/53.55274/10.00677
Or Cologne https://www.openstreetmap.org/#map=18/50.94319/6.95853
Or Paris Gare du Nord https://www.openstreetmap.org/#map=17/48.88156/2.35623
Or London Kings Cross https://www.openstreetmap.org/#map=18/51.53194/-0.12326
Regards Sebastian
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

On 21 March 2019 11:26:39 am AEDT, Thomas Manson  
wrote:
Looking at Central Station, Sydney, the platform names are things like 
'Platform 4+5'. (https://www.openstreetmap.org/relation/6015392)


>From my reading of 
>https://wiki.openstreetmap.org/wiki/Tag%3Apublic_transport%3Dplatform, this 
>should be
the name of the station , so in this case that would be either Central or 
Central Station, with the platform numbers as the ref tag (which is already 
populated).

1) First of all, is my understanding correct? It should be the station name.
2) Secondly, should the name be Central or Central Station (assuming 1 is 
correct)?

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

Re: [Talk-es] Perdido con Overpass Api

[Miguel de Dios Matias]

Gracias lo estoy estudiando, muy buena documentación.

Saludos.

El lun., 18 mar. 2019 a las 18:59, Santiago Higuera (<
shigu...@mercatorlab.com>) escribió:

> Echa un vistazo a este manual que hice, por si te ayuda. Es el capítulo 8
>
> https://iceosm2016.readthedocs.io/en/latest/
>
> Un saludo
>
> Santiago Higuera
>
>
> El 18/3/19 a las 18:21, Miguel de Dios Matias escribió:
>
> Buenas.
>
> He leído la documentación de overpass api y sigo mas o menos perdido.
>
> Os cuento lo que intento hacer, sacar la silueta de un país, estoy
> probando con España.
>
> Con admin_level=2 me saca los km de costa añadidos a la frontera de tierra
> y con línea costa no me saca la frontera con Portugal por ejemplo.
>
> Os pego las queries (que están mal) pero es que todavía no se como filtrar
> de una relación (España) la caminos que la componen (no se si hay alguno
> etiquetado como frontera del país sin trocito de mar).
>
> (
> rel["name"="España"];
>   way["natural"="coastline"]({{bbox}});
> );
> out geom;
>
>
>
>
> area["name"="España"]->.country;
> way(area.country)["natural"="coastline"];
> out geom;
>
>
>
>
>
> area["name"="España"]->.country;
> // gather results
> (
>   // query part for: “admin_level=10”
>   node["admin_level"="2"](area.country);
>   way["admin_level"="2"](area.country);
>   relation["admin_level"="2"](area.country);
> );
> out geom;
>
> Saludos.
>
> ___
> Talk-es mailing 
> listTalk-es@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-es
>
>
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [OSM-talk-fr] Overpass API en grève

[althio]

Merci à toi Roland pour tout ton travail et ton annonce sur la liste
talk-fr !

Benoît


On Thu, 21 Mar 2019 at 21:06, Roland Olbricht 
wrote:

> Bonjour,
>
> l'Overpass API a returnée à operation normale.
>
> Je veux remercier l'association OpenStreetMap France pour la traduction
> de l'information sur la problème a
> https://www.openstreetmap.fr/copyright-article-13/
>
> Roland
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Overpass API en grève

[Roland Olbricht]

Bonjour,

l'Overpass API a returnée à operation normale.

Je veux remercier l'association OpenStreetMap France pour la traduction
de l'information sur la problème a
https://www.openstreetmap.fr/copyright-article-13/

Roland

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

Re: [OSM-talk] Overpass API turned off due to Upload Filter thread

[Roland Olbricht]

Hello everybody,

Overpass API is now back to normal operations. Thank you for your
understanding.

To ensure that OpenStreetMap will have a place in the future, it still
makes sense to phone (yes, phone) your member of the EP. Platforms that
assist on that are:
https://pledge2019.eu/en
https://saveyourinternet.eu/act/

If you need information on the background, I still suggest
https://www.openstreetmap.de/uf/en.html

Best regards,
Roland

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

Re: [Talk-de] Overpass API wegen Upload-Filtern temporär aus

[Roland Olbricht]

Hallo zusammen,

danke für das Verständnis und die positive Rückmeldung. Die Overpass API
ist jetzt wieder im Normalbetrieb.

Es ergibt natürlich trotzdem Sinn, weiterhin die EU-Abgeordneten
anzurufen, siehe
https://www.openstreetmap.de/uf/

Viele Grüße,

Roland

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

Re: [OSM-talk-be] Looking how tagging "ijskelder"

[Lionel Giard]

Not being doesn't mean it is badly tagged, it just mean that the map on the
website (which is only one map out of many) doesn't show this kind of
details. OpenStreetMap is still a database first, and not a map. Try to not
"map for the renderer" but rather stay with correct tagging. And if you
want to show some data that are not rendered, you can always use custom
maps like umap.

Or one way to see it on maps and still be correct for tagging is : if this
is an historic "ice cellar" you can always put historic=yes (or ruins)
and/or tourism=attraction if relevant and interesting for tourism. The tag
"historic=*" allow it to be visible on the http://gk.historic.place/ map
(only historical elements) and tourism=attraction shows up on the osm map
itself).

Le jeu. 21 mars 2019 à 17:07, Hubert Christiaen <
hubert.christi...@telenet.be> a écrit :

> Op 21/03/19 om 13:08 schreef Marc Gemis:
> > There is a proposal for cellar entries that mentions icehouse:
> >
> https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:man_made%3Dcellar_entrance
>
> I tried that for a ice cellar in Heverlee, but it was not rendered on
> the map.
>
> Sincerely,
> Hubert
>
> --
> Hubert Christiaen
> Bloesemlaan  17
> 3360 Korbeek-Lo
> Belgium
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [Talk-us] Proposed mechanical edit - remove objects that are not existing according to source of GNIS import that added them

[Martijn van Exel]

> On Mar 21, 2019, at 12:35 PM, Mark Wagner  wrote:
> 
> On Wed, 20 Mar 2019 21:46:59 -0600
> Martijn van Exel mailto:m...@rtijn.org>> wrote:
> 
>>> On Mar 20, 2019, at 9:01 AM, Mateusz Konieczny
>>>  wrote:
>>> 
>>> I plan to run an automated edit that will revert part of the GNIS
>>> import that added them and delete objects that never had any reason
>>> to appear in the OSM database in any form, at least according to
>>> GNIS data.
>>> 
>>> Please comment no matter what you think about this idea! I will not
>>> make the edit without a clear support so please comment if you think
>>> that it is a good idea and if you think that it should not be
>>> done.   
>> 
>> 
>> Thanks for bringing the idea up. It actually did come up fairly
>> recently on Slack
>> https://osmus.slack.com/archives/C029HV951/p1550176430103000 
>> 
>> My view is that we would be missing an opportunity to have mappers
>> review these locations and update the areas concerned. These nodes
>> exist mostly in ‘undermapped' / remote areas that could use some
>> human mapper attention. So I’d be in favor of trying to resolve this
>> using some human driven cleanup first.
> 
> My experience is that this will mostly just make things worse.
> 
> There was a MapRoulette task a while back for cleaning up
> unmodified GNIS-imported schools.  There were only a few of them left
> around me, but the most common result was that an armchair mapper would
> drag the node to a nearby non-house-looking building, trace the
> building, and merge it with the imported node.  Not one of these was
> actually a school.
> 

Do you think this could have been prevented had there been better instructions?

Martijn

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

Re: [Talk-de] Overpass API wegen Upload-Filtern temporär aus

[Harald Schwarz]

Hallo Roland, hallo OSM-Gemeinde

ich verzichte gerne für einige Zeit auf mein Lieblingswerkzeug overpass,
wenn damit gezeigt werden kann, das die Internet-Community und auch Communities 
wie OpenStreetMap damit aufzeigen, dass sie mit den geplanten Änderungen
zum EU-Copyrightgesetz nicht einverstanden sind.

Ich finde Deine Entscheidung overpass abzuschalten gut und sage Danke.

Grüße aus Ratingen
   Harald Schwarz
   black_bike

PS: Hier mal die Antwort von overpass im Klartext. Die Idee den Protest in 
OpenStreetMap-Tags zu pacḱen ist für sich allein schon gut.



The data included in this document is from www.openstreetmap.org. The 
data is made available under ODbL.


  
  
  
  
  
  
  




https://www.openstreetmap.de/uf/en.html"/>
https://www.openstreetmap.de/uf/"/>
  
  






https://www.openstreetmap.de/uf/en.html"/>
https://www.openstreetmap.de/uf/"/>

  






> Gesendet: Donnerstag, 21. März 2019 um 05:26 Uhr
> Von: "Roland Olbricht" 
> An: "Openstreetmap allgemeines in Deutsch" 
> Betreff: [Talk-de] Overpass API wegen Upload-Filtern temporär aus
>
> Hallo zusammen,
> 
> am 26. März soll das EU-Parlament über eine Urheberrechtsreform
> abstimmen, die als Seiteneffekt unter anderem OpenStreetMap gefährdet.
> Details siehe
> https://www.openstreetmap.de/uf/
> 
> Um alle Nutzer auf die Möglichkeiten zu Protesten hinzuweisen, schließen
> sich mehrere OSM-Dienste einschließlich der Overpass API dem heutigen
> Aktionstag an. Bei der Overpass API dauert die Unterbrechung bis ca. 21 Uhr.
> 
> Nutzer, die statt der normalen Suchergebnisse das Informationsergebnis
> sehen, können die URL temporär auf
> https://overpass-api.de/no_art11art13/
> ändern. Diese temporäre URL wird dann mit der Wiederherstellung des
> normalen Betriebs wieder abgeschaltet.
> 
> Ich bedauere die Unannehmlichkeiten, erinnere aber daran, dass dies der
> Vermeidung weitaus größerer Unannehmlichkeiten dient.
> 
> Viele Grüße,
> 
> Roland
> 
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-de
>

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

Re: [Talk-ca] FW: Building Import

[John Whelan]

I like the idea of building a consensus on a building import.

More seriously if we can get any sort of consensus I'll be more than happy.

Cheerio John

Begin Daniel wrote on 2019-03-21 2:40 PM:


Oups, I still miss the “reply all” button

*From:*jfd...@hotmail.com
*Sent:* Thursday, March 21, 2019 14:36
*To:* 'Nate Wessel'
*Subject:* RE: [Talk-ca] Building Import

Hi all,

Concerning the pre-processing, let’s try/check first the 
“orthogonalization” component then, if there is a consensus on the 
validity of the result, we can build on it J


Daniel

*From:*Nate Wessel [mailto:bike...@gmail.com]
*Sent:* Thursday, March 21, 2019 14:30
*To:* John Whelan
*Cc:* talk-ca@openstreetmap.org
*Subject:* Re: [Talk-ca] Building Import

I've specifically and repeatedly requested that the tasking manager be 
taken down while this project is reworked... though that doesn't 
pertain directly to the email I just sent.


Nate Wessel
Jack of all trades, Master of Geography, PhD candidate in Urban Planning
NateWessel.com 

On 3/21/19 2:02 PM, John Whelan wrote:

Nate are you requesting something specific on the Canadian task
manager for Toronto at this time or would you prefer to look
through Daniel's work first?

Thanks

Cheerio John

Nate Wessel wrote on 2019-03-21 1:49 PM:

Daniel,

This is exciting news! After much talk on this list, it seems we
may have some actual progress toward fixing the various data
quality issues. Would you mind sharing some of your code, or a
description of your workflow here or on GitHub or the like so we
can take a look?

One thing you didn't mention which I think will be really
critical, especially in central Toronto: We need to remove
buildings from the import dataset that may already be mapped in
OSM. That is, buildings that overlap with existing buildings. For
this import to make any sense in Central Toronto, we need
conflation to move slowly, and in smaller, more manageable steps.
Buildings that are already mapped should be checked manually at a
later time in batches that a skilled human can manage in less than
an hour. The tasking manager as it's currently set up would have
all of downtown conflated by hand in one task by a single mapper -
a recipe for disaster I'm sure, given how detailed the map is in
that area.

Cheers,

Nate Wessel
Jack of all trades, Master of Geography, PhD candidate in Urban
Planning
NateWessel.com 

On 3/19/19 12:58 PM, Begin Daniel wrote:

Hi all,

As mentioned a few weeks ago, I have almost completed the
development of a clean-up tool for the data to be imported.

So far, it removes nonessential vertices, orthogonalizes
building corners when reasonable and ensures walls’ alignment
within given tolerances. Building footprints that can’t be
processed completely are flagged accordingly, so they could be
examined thoroughly at import time.

Eventually, It should be easy to remove overlapping buildings
(potentially generated from a 3d mapping), but I doubt that
splitting terrace into individual buildings can be done
automatically.

The tool uses some parameters that need to be adjusted. I
would like that those who are interested in this aspect of the
import send me benchmark data that could be problematic. I
will process them to adjust parameters and/or the tool, and I
will send back the results to the sender for a thorough
examination.

I should soon document the process in the “Canada Building
Import” wiki page (in a pre-processing section).

Thought? Comments?

Daniel

___

Talk-ca mailing list

Talk-ca@openstreetmap.org 

https://lists.openstreetmap.org/listinfo/talk-ca

___

Talk-ca mailing list

Talk-ca@openstreetmap.org 

https://lists.openstreetmap.org/listinfo/talk-ca

-- 


Sent from Postbox





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


--
Sent from Postbox 

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

[Talk-ca] FW: Building Import

[Begin Daniel]

Oups, I still miss the "reply all" button

From: jfd...@hotmail.com
Sent: Thursday, March 21, 2019 14:36
To: 'Nate Wessel'
Subject: RE: [Talk-ca] Building Import

Hi all,
Concerning the pre-processing, let's try/check first the "orthogonalization" 
component then, if there is a consensus on the validity of the result, we can 
build on it :)

Daniel

From: Nate Wessel [mailto:bike...@gmail.com]
Sent: Thursday, March 21, 2019 14:30
To: John Whelan
Cc: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Building Import


I've specifically and repeatedly requested that the tasking manager be taken 
down while this project is reworked... though that doesn't pertain directly to 
the email I just sent.
Nate Wessel
Jack of all trades, Master of Geography, PhD candidate in Urban Planning
NateWessel.com
On 3/21/19 2:02 PM, John Whelan wrote:
Nate are you requesting something specific on the Canadian task manager for 
Toronto at this time or would you prefer to look through Daniel's work first?

Thanks

Cheerio John

Nate Wessel wrote on 2019-03-21 1:49 PM:

Daniel,

This is exciting news! After much talk on this list, it seems we may have some 
actual progress toward fixing the various data quality issues. Would you mind 
sharing some of your code, or a description of your workflow here or on GitHub 
or the like so we can take a look?

One thing you didn't mention which I think will be really critical, especially 
in central Toronto: We need to remove buildings from the import dataset that 
may already be mapped in OSM. That is, buildings that overlap with existing 
buildings. For this import to make any sense in Central Toronto, we need 
conflation to move slowly, and in smaller, more manageable steps. Buildings 
that are already mapped should be checked manually at a later time in batches 
that a skilled human can manage in less than an hour. The tasking manager as 
it's currently set up would have all of downtown conflated by hand in one task 
by a single mapper - a recipe for disaster I'm sure, given how detailed the map 
is in that area.

Cheers,
Nate Wessel
Jack of all trades, Master of Geography, PhD candidate in Urban Planning
NateWessel.com
On 3/19/19 12:58 PM, Begin Daniel wrote:
Hi all,
As mentioned a few weeks ago, I have almost completed the development of a 
clean-up tool for the data to be imported.
So far, it removes nonessential vertices, orthogonalizes building corners when 
reasonable and ensures walls' alignment within given tolerances. Building 
footprints that can't be processed completely are flagged accordingly, so they 
could be examined thoroughly at import time.
Eventually, It should be easy to remove overlapping buildings (potentially 
generated from a 3d mapping), but I doubt that splitting terrace into 
individual buildings can be done automatically.
The tool uses some parameters that need to be adjusted. I would like that those 
who are interested in this aspect of the import send me benchmark data that 
could be problematic. I will process them to adjust parameters and/or the tool, 
and I will send back the results to the sender for a thorough examination.
I should soon document the process in the "Canada Building Import" wiki page 
(in a pre-processing section).

Thought? Comments?

Daniel



___

Talk-ca mailing list

Talk-ca@openstreetmap.org

https://lists.openstreetmap.org/listinfo/talk-ca

___

Talk-ca mailing list

Talk-ca@openstreetmap.org

https://lists.openstreetmap.org/listinfo/talk-ca

--
Sent from 
Postbox
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-us] Proposed mechanical edit - remove objects that are not existing according to source of GNIS import that added them

[Mark Wagner]

On Wed, 20 Mar 2019 21:46:59 -0600
Martijn van Exel  wrote:

> > On Mar 20, 2019, at 9:01 AM, Mateusz Konieczny
> >  wrote:
> > 
> > I plan to run an automated edit that will revert part of the GNIS
> > import that added them and delete objects that never had any reason
> > to appear in the OSM database in any form, at least according to
> > GNIS data.
> > 
> > Please comment no matter what you think about this idea! I will not
> > make the edit without a clear support so please comment if you think
> > that it is a good idea and if you think that it should not be
> > done.   
> 
> 
> Thanks for bringing the idea up. It actually did come up fairly
> recently on Slack
> https://osmus.slack.com/archives/C029HV951/p1550176430103000 
> 
> My view is that we would be missing an opportunity to have mappers
> review these locations and update the areas concerned. These nodes
> exist mostly in ‘undermapped' / remote areas that could use some
> human mapper attention. So I’d be in favor of trying to resolve this
> using some human driven cleanup first.

My experience is that this will mostly just make things worse.

There was a MapRoulette task a while back for cleaning up
unmodified GNIS-imported schools.  There were only a few of them left
around me, but the most common result was that an armchair mapper would
drag the node to a nearby non-house-looking building, trace the
building, and merge it with the imported node.  Not one of these was
actually a school.

-- 
Mark

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

[OSM-talk-be] save-the-internet - manifestaties nu zaterdag 23 maart

[Karel Adams]

Met enige verbazing zag ik de aankondiging van manifestaties overmorgen 
zaterdag, tegen een wetgevend initiatief op Europees niveau. Nog 
verbazender dat ik er nog niet van hoorde langs enige andere weg, bv. 
alhier.


https://savetheinternet.info/demos

Drie mogelijkheden:

* dit is niet ernstig

* dit is ernstig, en er wordt ook bij ons gemanifesteerd. Zoja: waar? 
wanneer?


* dit is ernstig, en er is nog niks georganiseerd. Zoja, zullen we 
afspreken in Brussel, nu zaterdag? Ik ben alvast graag beschikbaar.





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

Re: [Talk-us] Proposed mechanical edit - remove objects that are not existing according to source of GNIS import that added them

[Mateusz Konieczny]

Mar 21, 2019, 6:18 PM by kevin.b.ke...@gmail.com:

> I, too, would appreciate seeing some sample data, let's say, some
> reasonable radius around 42.8257, -73.8790.  That's more to make sure
> that the technology is working right and not wetting on stuff that's
> already fixed, but of course, I'd check to verify my tentative
> conclusion that (historic) doesn't tag anything useful.
>

I uploaded files to https://github.com/matkoniecz/objects_for_deletion 
 and linked in

https://wiki.openstreetmap.org/wiki/Mechanical_Edits/Mateusz_Konieczny_-_bot_account/remove_objects_that_are_not_existing_according_to_source_of_import_that_added_them#List_of_candidates

For now just file with all nodes in .osm file (can be opened with JOSM - File | 
Open menu).
As it is limited to nodes it works fairly well and can be browsed without 
performance issues.

I uploaded also file with objects very far away from 42, -73 deleted but it 
turned out to produce 
larger file, probably JOSM recorded deletions.

I can produce later something more user friendly if that would be useful and 
.osm files are too complicated
- let me know if that would be useful!

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

Re: [Talk-us] Proposed mechanical edit - remove objects that are not existing according to source of GNIS import that added them

[Mateusz Konieczny]

Mar 21, 2019, 6:23 PM by cliff...@snowandsnow.us:

>
>
> On Thu, Mar 21, 2019 at 9:52 AM Mateusz Konieczny <> matkoni...@tutanota.com 
> > > wrote:
>
>> Good idea, independent check would be welcomed!
>>
>> Something from Seattle region would be OK, right?
>>
>> If my googling went right the you are probably interested
>> in data around
>> https://www.openstreetmap.org/user/Glassman/history#map=8/47.780/-122.388 
>> 
>>
>>
>
> Seattle area is fine or Skagit County to the north. Seattle would give me 
> more nodes to review which is good.
>
I uploaded files and linked in

https://wiki.openstreetmap.org/wiki/Mechanical_Edits/Mateusz_Konieczny_-_bot_account/remove_objects_that_are_not_existing_according_to_source_of_import_that_added_them#List_of_candidates

For now just file with all nodes in .osm file (can be opened with JOSM). As it 
is limited to nodes
it works fairly well and ca be browsed without performance issues.

I uploaded also file with objects very far away from Seattle deleted but it 
turned out to produce larger file,
probably JOSM recorded deletions.

I can produce later something more user friendly if that would be useful and 
.osm files are too complicated
- let me know if that would be useful!
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-it] [talk-it] Falsi guadi

[Volker Schmidt]

Per caso mi sono imbattuto (e sono sicuro che non sono il primo) nel
problema dei "passaggi a livello" di highway e waterway.
Ci ne sono sicuramente decine di migliaia solo in Italia.
Cercate con keepright.at:
> intersections without junctions > highway.- waterway

Buon divertimento

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

Re: [Talk-ca] Building Import

[John Whelan]

Nate are you requesting something specific on the Canadian task manager 
for Toronto at this time or would you prefer to look through Daniel's 
work first?


Thanks

Cheerio John

Nate Wessel wrote on 2019-03-21 1:49 PM:


Daniel,

This is exciting news! After much talk on this list, it seems we may 
have some actual progress toward fixing the various data quality 
issues. Would you mind sharing some of your code, or a description of 
your workflow here or on GitHub or the like so we can take a look?


One thing you didn't mention which I think will be really critical, 
especially in central Toronto: We need to remove buildings from the 
import dataset that may already be mapped in OSM. That is, buildings 
that overlap with existing buildings. For this import to make any 
sense in Central Toronto, we need conflation to move slowly, and in 
smaller, more manageable steps. Buildings that are already mapped 
should be checked manually at a later time in batches that a skilled 
human can manage in less than an hour. The tasking manager as it's 
currently set up would have all of downtown conflated by hand in one 
task by a single mapper - a recipe for disaster I'm sure, given how 
detailed the map is in that area.


Cheers,

Nate Wessel
Jack of all trades, Master of Geography, PhD candidate in Urban Planning
NateWessel.com 

On 3/19/19 12:58 PM, Begin Daniel wrote:


Hi all,

As mentioned a few weeks ago, I have almost completed the development 
of a clean-up tool for the data to be imported.


So far, it removes nonessential vertices, orthogonalizes building 
corners when reasonable and ensures walls’ alignment within given 
tolerances. Building footprints that can’t be processed completely 
are flagged accordingly, so they could be examined thoroughly at 
import time.


Eventually, It should be easy to remove overlapping buildings 
(potentially generated from a 3d mapping), but I doubt that splitting 
terrace into individual buildings can be done automatically.


The tool uses some parameters that need to be adjusted. I would like 
that those who are interested in this aspect of the import send me 
benchmark data that could be problematic. I will process them to 
adjust parameters and/or the tool, and I will send back the results 
to the sender for a thorough examination.


I should soon document the process in the “Canada Building Import” 
wiki page (in a pre-processing section).


Thought? Comments?

Daniel


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

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


--
Sent from Postbox 

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

Re: [OSM-talk] Overpass API turned off due to Upload Filter thread

[Norbert Renner]

Yes, achavi fails with an error because the result is not in the
expected Augmented Diff format.

Norbert

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

Re: [Talk-us] Proposed mechanical edit - remove objects that are not existing according to source of GNIS import that added them

[Clifford Snow]

On Thu, Mar 21, 2019 at 9:52 AM Mateusz Konieczny 
wrote:

> Good idea, independent check would be welcomed!
>
> Something from Seattle region would be OK, right?
>
> If my googling went right the you are probably interested
> in data around
> https://www.openstreetmap.org/user/Glassman/history#map=8/47.780/-122.388
>
>
Seattle area is fine or Skagit County to the north. Seattle would give me
more nodes to review which is good.

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

Re: [Talk-us] Gated communities

[Evan Derickson]

I think there should be a new access tag for the "with permission only, but
you are likely to get it" case. Years ago OsmAnd tried to send me on a
"shortcut" through a military base while I was cycling. It turned out that
I could've used the road in question *if* I had contacted the base in
advance and gotten a recreation permit. For now that road is tagged as
access=private, but that doesn't tell the user that they can use it if they
plan ahead.

That is a little different from the case we have here, which seems to me
more like the difference between "access=private" and
"access=extra_private". Without creating new tags, I think the
access=private/destination distinction is the closest we can get to reality.

On Thu, Mar 21, 2019 at 9:32 AM Mateusz Konieczny 
wrote:

>
>
>
> Mar 21, 2019, 4:11 PM by kevin.b.ke...@gmail.com:
>
> On Thu, Mar 21, 2019 at 3:01 AM Mateusz Konieczny
>  wrote:
>
> For start, "residents only" gate is for me clearly access=private.
>
> "manned main gate" - is access strongly restricted?
> If nearly everybody, including vehicles, is let in I would tag it
> access=yes.
> It would also mean that access=destination would be better than
> access=private
> for inner ways of community.
>
> If access is strongly filtered (entrance requires permission from resident
> or
> guard is likely to resuse) then I would tag both gates access=private.
> Though it means that these gates are again not distinguishable.
>
>
> In practice, for the gated communities that I'm familiar with, there's
> not that significant a difference between access=destination and
> access=private at the main gate from this standpoint. If you have
> business in the community - pretty much equivalent to 'your
> destination is inside the community' - you're extremely likely to have
> the permission of a resident or business owner inside the gates.
> Nevertheless, if you're not a resident with a key card, you're not
> going to get through the automated gates. So access=destination for
> the main gate is in theory no more permissive than access=private, but
> gives a router a strong indication that "here is the correct entrance
> for visitors."
>
> I agree that access=destination is also better than access=private for
> roads inside the gate that are usable by visitors. (access=private is
> appropriate for service ways that lead to residents-only parking and
> similar things.)
>
> AFAIK access=destination is not limited to "I have permission from someone
> within", it also covers things like "I want to leave promotional
> leaflets", or
> "I want to walk around".
>
> It is rather for "no thru traffic" / "local traffic only" than "with
> permission only".
>
> Though I have no idea how to distinguish
> "with permission only, you are likely to get it if you have a good reason"
> and
> "with permission only, to get it you need to be an owner of a flat"
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
-- 

--
Evan Derickson
(360) 402-6494
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Proposed mechanical edit - remove objects that are not existing according to source of GNIS import that added them

[Kevin Kenny]

On Thu, Mar 21, 2019 at 10:31 AM Martijn van Exel  wrote:
> The benefit is that it gives mappers a reason to examine places - not just 
> the disappeared feature itself but also the area around it - that would 
> otherwise go unexamined. Since we have so much unexamined space in the U.S., 
> any opportunity to spark mappers’ curiosity about some of that space, is a 
> welcome trigger.

I need no incentive like that, and no mapper that I've corresponded
with does.  I'm still in the middle of an area where TIGER mapping is
absolutely atrocious, and I've cleaned only small corners. I've found
that it's the best use of my very limited time to confine my edits to
places that I've visited or intend to visit, which is why you'll see
most of my mapping taking place in my own neighbourhood, in the
vicinity of hiking trails, on the roads that I've travelled to get to
the trails, and the imports that I curate with respect to the
boundaries of public lands.

I've edited and conflated a bunch of GNIS points. I have yet to see
one marked as (historic) that was of the least bit of use. For the
best of them, they designate a building that is still standing but has
been repurposed. If I'm mapping buildings, I'll get around to that one
in any case. If I'm not micromapping to the level of individual
buildings, the information that "the private house here used to be a
two-room schoolhouse," is simply a distraction. Even if I am mapping
buildings, often the remodelling is so extensive that I can't spot any
indicia that it was once a schoolhouse, and can't even state with
confidence that the building wasn't demolished with a new building
constructed on the site. For the limited sample of (historic) GNIS
points that I've encountered, there is simply zero value to OSM
(beyond possibly the spot elevation, which is also often of
questionable quality.)

I can't speak to OHM. I've never contributed to that project. I
propose to let those who do contribute to it manage their own data
imports, and judge the value of (historic) GNIS data only with respect
to OSM, the project at hand.

> It may feel like a time sink for some, but my hope is that others will feel 
> it’s an interesting exercise to improve the map.

I understand in principle - but I don't see bad GNIS data as being any
greater incentive than bad TIGER data - and the anti-import crowd hold
the failure of the bad TIGER data to recruit mappers to fix it as a
model for why imports in general have a negative impact on the
community. Moreover, I've tried MapRoulette a few times, and every
time, come away with a mix of, "I don't have enough local knowledge to
do a good job here," and "I can make better progress cleaning other
things up closer to home." Most of the things it gives me, I wind up
clicking "too hard," while possibly tidying something else.

> Stepping back a bit, the urge to fix previous automated edits with new 
> automated fixes is understandable, but it may lead to a more casual approach 
> to imports and automated edits, because we basically say with each fix that 
> ill-informed automated map edits can always be fixed with more automated 
> edits later. We’ve already gone down that path in the U.S. quite far, so we 
> should proceed with extra care - unless we as a community decide that that is 
> the nature of OSM in this country. It isn’t to me.

Merciful heavens, no! Still, the fact remains that we have a bunch of
botched imports from the early days of mapping in the US. No,
'botched' is too strong a term. They were done well according to the
practice of the time. They significantly advanced the usefulness of
the map when they happened. Still, in light of what we've learned
since that time, they fall catastophically short of the data quality
that we now expect of an import. Few, if any, of us argue in favour of
importing at even close to that level of carelessness. Are you really
arguing that making it as laborious as possible to repair _known_ bad
data in these early imports is desirable, in order to discourage
future reckless imports?  That doesn't strike me as the way to make
forward progress.

For what it's worth I speak as someone who's, on a much smaller scale,
taken on the repair of an early import that was of unacceptably loiw
quality by today's standards. Check out
https://www.openstreetmap.org/user/ke9tv-nysdec-lands/history for how
much work *that* was. Without developing significant automation (a
script that worked off PostGIS queries and connected to the JOSM API
to set everything up for manual conflation), I'd not have been able to
complete the task. I won't say that the results are perfect - nothing
ever is - but it's a whale of a lot better than what was there before,
and I use the result with confidence for guidance in the field. (And
yes, the project was discussed on talk-us and imports, and wikified at
https://wiki.openstreetmap.org/wiki/NYS_DEC_Lands - so I offer at
least the semblance of due diligence.).

So - don't tolerate 

Re: [Talk-us] Proposed mechanical edit - remove objects that are not existing according to source of GNIS import that added them

[Mateusz Konieczny]

Good idea, independent check would be welcomed!

Something from Seattle region would be OK, right?

If my googling went right the you are probably interested
in data around
https://www.openstreetmap.org/user/Glassman/history#map=8/47.780/-122.388

Mar 21, 2019, 5:43 PM by cliff...@snowandsnow.us:

> I'm in favor of the bot but I'd like to review a sample of the data being 
> removed in my area. The purpose is to test the assumption that the data is of 
> no use.
>
> Best,
> Clifford
>

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

Re: [Talk-us] Proposed mechanical edit - remove objects that are not existing according to source of GNIS import that added them

[Clifford Snow]

I'm in favor of the bot but I'd like to review a sample of the data being
removed in my area. The purpose is to test the assumption that the data is
of no use.

Best,
Clifford

On Thu, Mar 21, 2019 at 9:32 AM Mateusz Konieczny 
wrote:

> Mar 21, 2019, 3:56 PM by m...@rtijn.org:
>
> Re-reading this I phrased this with more hyperbole than I intended, sorry.
>
> I see no problem here, after all lack of control over automated edit is
> how we ended
> in this situation.
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>


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

Re: [Talk-us] Proposed mechanical edit - remove objects that are not existing according to source of GNIS import that added them

[Mateusz Konieczny]

Mar 21, 2019, 3:56 PM by m...@rtijn.org:

> Re-reading this I phrased this with more hyperbole than I intended, sorry.
>
I see no problem here, after all lack of control over automated edit is how we 
ended 
in this situation.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Gated communities

[Mateusz Konieczny]

Mar 21, 2019, 4:11 PM by kevin.b.ke...@gmail.com:

> On Thu, Mar 21, 2019 at 3:01 AM Mateusz Konieczny
> <> matkoni...@tutanota.com > > wrote:
>
>> For start, "residents only" gate is for me clearly access=private.
>>
>> "manned main gate" - is access strongly restricted?
>> If nearly everybody, including vehicles, is let in I would tag it access=yes.
>> It would also mean that access=destination would be better than 
>> access=private
>> for inner ways of community.
>>
>> If access is strongly filtered (entrance requires permission from resident or
>> guard is likely to resuse) then I would tag both gates access=private.
>> Though it means that these gates are again not distinguishable.
>>
>
> In practice, for the gated communities that I'm familiar with, there's
> not that significant a difference between access=destination and
> access=private at the main gate from this standpoint. If you have
> business in the community - pretty much equivalent to 'your
> destination is inside the community' - you're extremely likely to have
> the permission of a resident or business owner inside the gates.
> Nevertheless,  if you're not a resident with a key card, you're not
> going to get through the automated gates. So access=destination for
> the main gate is in theory no more permissive than access=private, but
> gives a router a strong indication that "here is the correct entrance
> for visitors."
>
> I agree that access=destination is also better than access=private for
> roads inside the gate that are usable by visitors. (access=private is
> appropriate for service ways that lead to residents-only parking and
> similar things.)
>
AFAIK access=destination is not limited to "I have permission from someone
within", it also covers things like "I want to leave promotional leaflets", or
"I want to walk around".

It is rather for "no thru traffic" / "local traffic only" than "with permission 
only".

Though I have no idea how to distinguish
"with permission only, you are likely to get it if you have a good reason"
and
"with permission only, to get it you need to be an owner of a flat"

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

Re: [Talk-us] Proposed mechanical edit - remove objects that are not existing according to source of GNIS import that added them

[Mateusz Konieczny]

Mar 21, 2019, 3:29 PM by m...@rtijn.org:

> The benefit is that it gives mappers a reason to examine places - not just 
> the disappeared feature itself but also the area around it - that would 
> otherwise go unexamined. Since we have so much unexamined space in the U.S., 
> any opportunity to spark mappers’ curiosity about some of that space, is a 
> welcome trigger. 
>
> It may feel like a time sink for some, but my hope is that others will feel 
> it’s an interesting exercise to improve the map. 
>
I think that existing issues detected by say Osmose are more than enough to 
encourage fixing stuff.

http://osmose.openstreetmap.fr/en/map/  
has massive amount of things to fix, even in well 
mapped areas.

Willing mappers are bottleneck, so whenever rare of bot-fixable
problems happens I think that it is a good idea to use it and spend human 
mapping time
on something more useful.

And if there is any danger of any area in USA running out of Maproulette or 
Osmose tasks - 
let me know and I will create something.

Especially Wikipedia-related one, as side effect of my project of finding 
tourism attractions
based on OSM data I created validator detecting various issues with wikipedia 
and wikidata tasks,
if anyone is interested I may run it for some part of USA.

> Stepping back a bit, the urge to fix previous automated edits with new 
> automated fixes is understandable, but it may lead to a more casual approach 
> to imports and automated edits, because we basically say with each fix that 
> ill-informed automated map edits can always be fixed with more automated 
> edits later. We’ve already gone down that path in the U.S. quite far, so we 
> should proceed with extra care - unless we as a community decide that that is 
> the nature of OSM in this country. It isn’t to me.
>
I fully support proper discussion before doing automatic changes, especially on 
larger scale and
ones that will delete items making them harder to reverse.

And I would be really irritated if someone would use this automatic edit 
proposal to 
support "my edit requires no discussion, after all sooner or later someone will 
fix my mess".

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

Re: [OSM-talk-fr] Des projets de construction pas sorti de terre !

[Vincent Bergeot]

Le 21/03/2019 à 12:38, Vincent Bergeot a écrit :

Le 21/03/2019 à 10:24, Bernard Lefrançois a écrit :
//>/> Le 20.03.19 à 14:58, Vincent Bergeot a écrit : />/>> https://www.openstreetmap.org/user/L3mp1ck4 />>//>//>/>> https://www.openstreetmap.org/user/Dupuiche />//>//>/je penche pour une agence d'archi, le fait que les 2 se retrouve sur 
une />/même zone ! /On peut rajouter à la liste:

https://www.openstreetmap.org/user/Y43l//En plus d'introduire des éléments encore à l'état de 
projet, ils ont une tendance à cartographier "pour faire joli"/. /Avec, en 
particulier, un usage abusif du tag natural=tree par exemple comme 
ici://https://www.openstreetmap.org/#map=18/43.73203/7.27437=N//J'ai peine à 
croire que le contributeur a une source fiable pour la position et la hauteur de chaque arbre!


sans juger de la validité des arbres et la source pour les hauteurs 
(entre guillemet, c'est un "autre sujet"), cependant effectivement on 
retrouve juste à coté 
(https://www.openstreetmap.org/way/59923#map=19/43.73198/7.27412) 
le même utilisateur précédemment signalé, 
https://www.openstreetmap.org/user/Dupuiche avec des constructions non 
visibles en imagerie et en cadastre... et sans élément externe pour la 
source...


Donc

  * https://www.openstreetmap.org/user/Y43l
  * https://www.openstreetmap.org/user/Dupuiche
  * https://www.openstreetmap.org/user/L3mp1ck4

Et je viens d'être moins sympa : 
https://www.openstreetmap.org/changeset/68368951#map=19/49.00294/2.23289




toujours pas de réaction des personnes interpellées mais un autre 
contributeur.


à plus


--
Vincent Bergeot

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

Re: [OSM-talk-be] Looking how tagging "ijskelder"

[Hubert Christiaen]

Op 21/03/19 om 13:08 schreef Marc Gemis:

There is a proposal for cellar entries that mentions icehouse:
https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:man_made%3Dcellar_entrance


I tried that for a ice cellar in Heverlee, but it was not rendered on 
the map.


Sincerely,
Hubert

--
Hubert Christiaen
Bloesemlaan  17
3360 Korbeek-Lo
Belgium


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

Re: [OSM-talk] Overpass API turned off due to Upload Filter thread

[François Lacombe]

Hi Steve,

Le jeu. 21 mars 2019 à 16:46, Steve Doerr  a
écrit :

> On 21/03/2019 05:21, Roland Olbricht wrote:
> > the Overpass API shows only an informative
> > result today. This will last until about 20:00 UTC.
>
> Could this be affecting nrenner.github.io/achavi, does anybody know?
>

Yes it does
I currently get  as answer.

All the best

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

[OSM-talk-fr] Article 13, directive droit d'auteur

[Benoit Fournier - OpenStreetMap France]

Bonjour la communauté OpenStreetMap France,

Suite à des discussions récentes et anciennes [1,2,3,4], l'association
OpenStreetMap France a décidé d'afficher sa protestation contre le projet
de directive européenne sur le droit d'auteur 'copyright' et en particulier
les intentions de l'article 13.

Deux actions ont été mises en place ce matin :

- une bannière sur l'accueil du site de l'association
http://www.openstreetmap.fr/
> Nous protestons aujourd'hui contre l'article 13 de la directive droit
d'auteur qui devrait être votée au parlement Européen le 26 mars 2019.
> Cette réforme menace l'Internet Libre et les valeurs d'ouverture propres
à OpenStreetMap.
> En savoir plus
> #SaveYourInternet

- un article sur le site de l'association
https://www.openstreetmap.fr/copyright-article-13/

Nous envisageons une action restreinte sur le service de tuiles, à définir
et mettre en place.

Benoît
OpenStreetMap France


[1] [osm-fr asso] Article 13, directive droit d'auteur
https://listes.openstreetmap.fr/wws/arc/association/2019-03/msg3.html

[2] [OSM-talk-fr] S'opposer à la directive européenne "Copyright in the
Digital Single Market"
https://lists.openstreetmap.org/pipermail/talk-fr/2018-September/089897.html

[3] [OSM-talk] Overpass API turned off due to Upload Filter thread
https://lists.openstreetmap.org/pipermail/talk/2019-March/082312.html

[4] [Osmf-talk] Turning off services and/or adding banners to protest
against the EU Copyright Directive
https://lists.openstreetmap.org/pipermail/osmf-talk/2019-March/006027.html
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-GB] Vector OSM

[Jez Nicholson]

https://www.klokantech.com/products/ ?

Mapbox tiles?

On Thu, 21 Mar 2019 15:19 chilton steve via Talk-GB, <
talk-gb@openstreetmap.org> wrote:

> I saw there was a discussion about vector tiles from OSM (…. at the SOTM
> 2018 BOF session with Richard Fairhurst?).
>
> I am giving a talk about OSM in June and wondered what the latest
> situation is.
>
> So, is there any moves to free server space and do the work to generate
> vector tiles directly. Likewise is any third-party delivering vector tiles
> from OSM data that I may have missed?
>
> Cheers
>
> Steve
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [OSM-talk] Overpass API turned off due to Upload Filter thread

[Steve Doerr]

On 21/03/2019 05:21, Roland Olbricht wrote:

the Overpass API shows only an informative
result today. This will last until about 20:00 UTC.


Could this be affecting nrenner.github.io/achavi, does anybody know?

--
Steve

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


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

Re: [Talk-GB] Milton Keynes Redways - How to Tag Consistently

[Peter Neale via Talk-GB]

Thanks to all for the helpful responses.
I have looked (again) at the OSM Tags for Routing at 
https://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions#United_Kingdomfrom
 which it is clear that foot=yes (for example) is implied by highway=cycleway.
However, Andy's question (if I understand it correctly) set me wondering 
whether there is any need to / benefit from distinguishing between foot=yes and 
foot=designated, etc.  
MK council, in their public mapping, imply that Redways are NOT (generally / 
universally) PROW.  However, they DO seem to be "designated" for foot and cycle 
(and wheelchairs etc.), so perhaps they should be tagged; bicycle=designated; 
foot=designated,etc.,which highway=cycleway does not imply.
Also, at the end of my original post, I asked:
"NamingI am not aware of any Redways that have unique names (someone will 
probably correct me on this), but I see several on OSM tagged with 
“name=Redway”.  Whilst I can see the attraction of doing this, I suspect that 
would not be considered good practice.  Should I delete that name, whenever I 
see it? "
Nobody seems to have commented on that yet (perhaps it got lost somewhere).  
Any views? 
Regards,

Peter

On Thursday, 21 March 2019, 13:54:20 GMT, Andy Townsend  
wrote:  
 
 On 21/03/2019 13:35, Ed Loach wrote:
> How tagging changes over time...
>
> RichardF wrote:
>> highway=cycleway, segregated=no achieves all that in two tags
>> rather than
>> seven. :)
> I remember
> https://wiki.openstreetmap.org/wiki/Milton_Keynes_Mapping_Party_2009
> where it looks like we (or at least I) only used highway=cycleway, e.g.
> https://www.openstreetmap.org/way/34669428/history
>
If they have some legal status beyond being "mere shared cycleways" 
would some sort of designation tag also make sense here?  Currently 
that's used for legal designations such as public footpaths, public 
bridleways (and also I think core paths in Scotland).

Best Regards,

Andy



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

[Talk-GB] Vector OSM

[chilton steve via Talk-GB]

I saw there was a discussion about vector tiles from OSM (…. at the SOTM 2018 
BOF session with Richard Fairhurst?).

I am giving a talk about OSM in June and wondered what the latest situation is.

So, is there any moves to free server space and do the work to generate vector 
tiles directly. Likewise is any third-party delivering vector tiles from OSM 
data that I may have missed?

Cheers

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

Re: [Talk-us] Gated communities

[Kevin Kenny]

On Thu, Mar 21, 2019 at 3:01 AM Mateusz Konieczny
 wrote:
> For start, "residents only" gate is for me clearly access=private.
>
> "manned main gate" - is access strongly restricted?
> If nearly everybody, including vehicles, is let in I would tag it access=yes.
> It would also mean that access=destination would be better than access=private
> for inner ways of community.
>
> If access is strongly filtered (entrance requires permission from resident or
> guard is likely to resuse) then I would tag both gates access=private.
> Though it means that these gates are again not distinguishable.

In practice, for the gated communities that I'm familiar with, there's
not that significant a difference between access=destination and
access=private at the main gate from this standpoint. If you have
business in the community - pretty much equivalent to 'your
destination is inside the community' - you're extremely likely to have
the permission of a resident or business owner inside the gates.
Nevertheless,  if you're not a resident with a key card, you're not
going to get through the automated gates. So access=destination for
the main gate is in theory no more permissive than access=private, but
gives a router a strong indication that "here is the correct entrance
for visitors."

I agree that access=destination is also better than access=private for
roads inside the gate that are usable by visitors. (access=private is
appropriate for service ways that lead to residents-only parking and
similar things.)

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

Re: [Talk-us] Proposed mechanical edit - remove objects that are not existing according to source of GNIS import that added them

[Martijn van Exel]

Re-reading this I phrased this with more hyperbole than I intended, sorry.

I do think we should learn from past mistakes and approach any automated edit, 
be it an import or a (subsequent) fix, with the proper diligence. Which is what 
we’re doing here, and I commend you for taking an open-minded approach in your 
initial email.

Martijn

> On Mar 21, 2019, at 8:29 AM, Martijn van Exel  wrote:
> 
> Stepping back a bit, the urge to fix previous automated edits with new 
> automated fixes is understandable, but it may lead to a more casual approach 
> to imports and automated edits, because we basically say with each fix that 
> ill-informed automated map edits can always be fixed with more automated 
> edits later. We’ve already gone down that path in the U.S. quite far, so we 
> should proceed with extra care - unless we as a community decide that that is 
> the nature of OSM in this country. It isn’t to me.
> 

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

Re: [OSM-talk-fr] Des projets de construction pas sorti de terre !

[Jérôme Seigneuret]

C'est déjà décrit

C'est un landcover=*

Mais peu utilisé en France

Le jeu. 21 mars 2019 à 13:58, Bernard Lefrançois 
a écrit :

> n’est ce pas plus sage cartographier ce paquet d’arbre comme un landuse ?
> je n’aurais pas rentré le détail de chaque arbre mais si quelqu’un le
> fait, je vois pas le soucis.
>
>
> Si j'ai émis des doutes, c'est parce que je ne pense pas que c'est dans
> l'esprit du wiki: "Marquage d'un arbre unique, parfois isolé ou
> significatif", mais je reconnais que le mot "parfois" laisse ouverte la
> discussion.
>
> Si on accepte l'utilisation du tag, il n'en reste pas moins que chaque
> natural=tree doit correspondre a un arbre réel, localisé à son emplacement
> réel.
>
> Or, les imageries utilisables (BD Ortho IGN, Bing) ne permettent pas
> d'arriver à ce niveau de précision.
> Pire, si on superpose les nœuds en question sur une image Ortho IGN, ça
> saute au yeux, il n'y a aucune relation.
>
> On pourrait envisager que le contributeur a utilisé une base de donnée
> d'un organisme disposant de moyens technologiques avancés (ONF ...).
> Mais pas de source citée, pas d'info sur la licence de ces éventuelles
> données.
>
> Quant à l'utilisation d'un landuse, on s'aperçoit que cette zone
> appartient déjà à un landuse=grass.
> Ce qui révèle peut-être une lacune d'OSM: comment décrire à la fois le
> couvert et le niveau du sol.
>
> ​
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-us] Proposed mechanical edit - remove objects that are not existing according to source of GNIS import that added them

[Harald Kliems]

On Thu, Mar 21, 2019 at 9:31 AM Martijn van Exel  wrote:

> The benefit is that it gives mappers a reason to examine places - not just
> the disappeared feature itself but also the area around it - that would
> otherwise go unexamined. Since we have so much unexamined space in the
> U.S., any opportunity to spark mappers’ curiosity about some of that space,
> is a welcome trigger.
>

I have certainly have had that experience when participating in various
MapRoulette challenges: You come for the non-existent landing strip; you
stay for half an hour to clean up the messy TIGER roads. However, given
that there are so many other MapRoulette tasks that will lead you to remote
areas and _can't_ be automated, I'm fully in support of Mateusz's automatic
edit.

 Harald (hobbesvsboyle)
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [OSM-co] Venezuela Refugee Crisis

[Ariel Nunez]

Thanks!

En espaniol para la lista: Al parecer el esfuerzo continua y estan
buscando solamente maperos que utilicen JOSM.

Si hay personas de Barranquilla interesadas en un mapathon en las
oficinas de Piensa Labs para dar un taller de JOSM, yo puedo dictarlo.

Saludos,
Ariel.

On Wed, Mar 20, 2019 at 8:43 AM Russell Deffner
 wrote:
>
> Hi Ariel and all,
>
> We are still working on Barranquilla. As you know, it is very densely 
> populated and will take some time to do right. Head to our tasking manager 
> https://tasks.hotosm.org/contribute?difficulty=ALL=AyudaVenezuela 
> for all related projects.
>
> Thank you,
> =Russ
>
> Russell Deffner
> https://hotosm.org
>
> On Mar 20, 2019, at 9:34 AM, Ariel Nunez  wrote:
>
> Hey Russell,
>
> Just seeing this on my inbox (I live in Barranquilla and have
> contributed a bit to the local map), how did this effort go?
>
> -a
>
> On Fri, Mar 1, 2019 at 6:34 PM  wrote:
>
>
> Perdona que solo hablo inglés, esta es una versión traducida de Google, 
> mensaje original a continuación ...
>
>
> Saludos a la comunidad de OSM Colombia!
>
>
> Soy Russell Deffner del Equipo Humanitario de OpenStreetMap (HOT). Se nos 
> pidió que viéramos cómo podríamos ayudar a la situación de los refugiados en 
> el norte de Colombia con mejores mapas base. Después de pensar en ello por 
> varios días y hablar con algunas personas de su comunidad, creemos que 
> nuestros esfuerzos pueden ayudar al completar los edificios de Barranquilla y 
> hemos creado un proyecto para ella: https://tasks.hotosm.org/project/5792
>
>
> También observamos detenidamente Barranquilla, ya que comprendemos la 
> dificultad de la cartografía allí. Por lo tanto, el proyecto actualmente está 
> restringido a solo mapeadores avanzados y les pedimos que utilicen JOSM solo 
> para mantener la calidad de los datos lo más alta posible. Espero que muchos 
> de ustedes participen o apoyen este esfuerzo y yo mismo, o mis colegas Theo y 
> Rebecca (cc'd), le informarán si planeamos realizar cambios importantes o si 
> esta situación continúa y decidimos hacerlo. mapa en cualquier otro lugar en 
> colombia.
>
>
> Siempre puede comunicarse con alguien enviando un correo electrónico a 
> activat...@hotosm.org (o si está interesado en ayudar a coordinar los 
> desastres a nivel mundial).
>
>
> Gracias, y por favor contáctenos si necesita algo,
>
> = Russ
>
>
>
>
> PD Actualmente estamos trabajando para que el proyecto sea traducido al 
> español.
>
>
>
>
> Traducción final
>
>
>
>
> Greetings OSM Colombia Community!
>
>
>
>
> I am Russell Deffner from the Humanitarian OpenStreetMap Team (HOT). We were 
> asked to look at how we might help the refugee situation in northern Colombia 
> with better basemaps.  After thinking on it for several days and talking with 
> a few individuals from your community, we think our efforts can help by 
> completing the buildings of Barranquilla and have created a project for it: 
> https://tasks.hotosm.org/project/5792
>
>
>
>
> We also took a long look at Barranquilla as we understand the difficulty of 
> the mapping there. Therefore, the project is currently restricted to only 
> advanced mappers and we are asking them to use JOSM only to keep the data 
> quality as high as possible. I hope many of you will participate or support 
> this effort and either myself, or my colleagues Theo and Rebecca (cc’d), will 
> let you know if we plan to make any major changes and/or if this situation 
> continues and we decide to map anywhere else in Colombia.
>
>
>
>
> You can always reach someone by emailing activat...@hotosm.org (or if you are 
> interested in helping coordinate disasters globally).
>
>
>
>
> Thank you, and please do reach out to us if you need anything,
>
>
> =Russ
>
>
>
>
> Russell Deffner
>
>
> Disaster Mapping Coordinator
>
>
> Email: russell.deff...@hotosm.org
>
>
> OSM/Skype: russdeffner
>
>
> Humanitarian OpenStreetMap Team (HOT)
>
>
> Web | Wiki | Blog | Contact | Donate
>
>
>
>
> ___
>
> Talk-co mailing list
>
> Talk-co@openstreetmap.org
>
> https://lists.openstreetmap.org/listinfo/talk-co

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

Re: [Talk-GB] Milton Keynes Redways - How to Tag Consistently

[Andy Townsend]

On 21/03/2019 13:35, Ed Loach wrote:

How tagging changes over time...

RichardF wrote:

highway=cycleway, segregated=no achieves all that in two tags
rather than
seven. :)

I remember
https://wiki.openstreetmap.org/wiki/Milton_Keynes_Mapping_Party_2009
where it looks like we (or at least I) only used highway=cycleway, e.g.
https://www.openstreetmap.org/way/34669428/history

If they have some legal status beyond being "mere shared cycleways" 
would some sort of designation tag also make sense here?  Currently 
that's used for legal designations such as public footpaths, public 
bridleways (and also I think core paths in Scotland).


Best Regards,

Andy



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

[talk-cz] Dnes nefunkční overpass turbo

[majka]

Viz přiložený obrázek, protest zhruba do devíti do večera. Na co já
nemyslím, původně to ve mě evokovalo trochu jinou grafiku ;)

[image: OT.png]
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [Talk-GB] Milton Keynes Redways - How to Tag Consistently

[Ed Loach]

How tagging changes over time...

RichardF wrote:
> highway=cycleway, segregated=no achieves all that in two tags
> rather than
> seven. :)

I remember 
https://wiki.openstreetmap.org/wiki/Milton_Keynes_Mapping_Party_2009
where it looks like we (or at least I) only used highway=cycleway, e.g. 
https://www.openstreetmap.org/way/34669428/history

Ed


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

Re: [Talk-GB] Milton Keynes Redways - How to Tag Consistently

[Richard Fairhurst]

Peter Neale wrote:
>So how should they be tagged for access? I believe it should be:
> highway=path  (but I see several tagged as highway=cycleway and both are
> shown in the Wiki
> at https://wiki.openstreetmap.org/wiki/Tag:highway=cycleway)
> foot=designated
> motor vehicle=permit (to allow the emergency vehicles and maintenance
> vehicles)
> moped=no 
> bicycle=designated
> horses=not specified
> segregated=no

highway=cycleway, segregated=no achieves all that in two tags rather than
seven. :)

It's also more meaningful for routers/renderers, which can default to
assuming "this was built to cycleway standards" (i.e. paved) rather than
"this is just a path of some sort" (i.e. who knows). Though by all means do
add surface=paved (or =asphalt) for clarity.

Richard



--
Sent from: http://gis.19327.n8.nabble.com/Great-Britain-f5372682.html

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

[OSM-talk-fr] Des projets de construction pas sorti de terre !

[Bernard Lefrançois]

   n’est ce pas plus sage cartographier ce paquet d’arbre comme un
   landuse ?
   je n’aurais pas rentré le détail de chaque arbre mais si quelqu’un
   le fait, je vois pas le soucis.


Si j'ai émis des doutes, c'est parce que je ne pense pas que c'est dans 
l'esprit du wiki: "Marquage d'un arbre unique, parfois isolé ou 
significatif", mais je reconnais que le mot "parfois" laisse ouverte la 
discussion.


Si on accepte l'utilisation du tag, il n'en reste pas moins que chaque 
natural=tree doit correspondre a un arbre réel, localisé à son 
emplacement réel.


Or, les imageries utilisables (BD Ortho IGN, Bing) ne permettent pas 
d'arriver à ce niveau de précision.
Pire, si on superpose les nœuds en question sur une image Ortho IGN, ça 
saute au yeux, il n'y a aucune relation.


On pourrait envisager que le contributeur a utilisé une base de donnée 
d'un organisme disposant de moyens technologiques avancés (ONF ...).
Mais pas de source citée, pas d'info sur la licence de ces éventuelles 
données.


Quant à l'utilisation d'un landuse, on s'aperçoit que cette zone 
appartient déjà à un landuse=grass.
Ce qui révèle peut-être une lacune d'OSM: comment décrire à la fois le 
couvert et le niveau du sol.


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

Re: [Talk-us] Proposed mechanical edit - remove objects that are not existing according to source of GNIS import that added them

[EthnicFood IsGreat]

Date: Thu, 21 Mar 2019 08:04:13 +0100 (CET)
From: Mateusz Konieczny 
Cc: Talk Us 
Subject: Re: [Talk-us] Proposed mechanical edit - remove objects that
are not existing according to source of GNIS import that added them



Mar 21, 2019, 4:46 AM by m...@rtijn.org:




On Mar 20, 2019, at 9:01 AM, Mateusz Konieczny <>> matkoni...@tutanota.com 
>> > wrote:

I plan to run an automated edit that will revert part of the GNIS
import that added them and delete objects that never had any reason to
appear in the OSM database in any form, at least according to GNIS data.

Please comment no matter what you think about this idea! I will not
make the edit without a clear support so please comment if you think
that it is a good idea and if you think that it should not be done.>>


Thanks for bringing the idea up. It actually did come up fairly recently on Slack > 
https://osmus.slack.com/archives/C029HV951/p1550176430103000 
>

My view is that we would be missing an opportunity to have mappers review these 
locations and update the areas concerned. These nodes exist mostly in 
‘undermapped' / remote areas that could use some human mapper attention. So I’d 
be in favor of trying to resolve this using some human driven cleanup first.


What is the benefit, during survey, of mapped places that are not existing 
anymore?

I encounter many during surveys (usually result of data getting outdated) and 
for me it was
always time sink (as I needed to check is it actually gone) and never useful in 
any way.

Note that it is not obvious, especially for beginner or data users, that all of 
this places
are not existing anymore.



Instead of deleting the features that don't exist anymore, couldn't they 
be moved over to OHM?


Mark



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

Re: [Talk-de] Overpass API wegen Upload-Filtern temporär aus

[Roland Olbricht]

Hallo zusammen,


Super, dass eine weiterhin funktionstüchtige Alternative eingerichtet
wurde -- leider erhalte ich dort aber nur einen 403-Fehler. Ist da
eventuell ein Konfigurationsfehler drin?


Der Zugriff z.B. mit der URL
https://overpass-api.de/no_art11art13/interpreter?data=out;
sollte funktionieren.

Je nach verwendetem Tool muss also entweder
https://overpass-api.de/no_art11art13/
als Basis-URL hinterlegt werden (z.B. bei Overpass Turbo,
"Einstellungen" > "Allgemeines") oder
https://overpass-api.de/no_art11art13/interpreter
anstelle von
https://overpass-api.de/api/interpreter
mit einem POST-Request kombiniert werden oder wie üblich die Anfrage per
GET an
https://overpass-api.de/no_art11art13/interpreter?
angehängt werden.

Viele Grüße,
Roland

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

Re: [OSM-talk-be] Looking how tagging "ijskelder"

[Marc Gemis]

There is a proposal for cellar entries that mentions icehouse:
https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:man_made%3Dcellar_entrance
Just as with caves, it's easy to map the entrance, but harder to map the inside.

m

On Thu, Mar 21, 2019 at 1:05 PM Jakka  wrote:
>
> https://nl.wikipedia.org/wiki/IJskelder
> de ijskelder (m)the icehouse
> ijskelder   ice cellar ; snow cellar
> Nothing on tag info ?
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be

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

[OSM-talk-be] Looking how tagging "ijskelder"

[Jakka]

https://nl.wikipedia.org/wiki/IJskelder
de ijskelder (m)the icehouse
ijskelder   ice cellar ; snow cellar
Nothing on tag info ?


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

Re: [Talk-us] US map rendering (Was: Re: Spot elevations collected as natural=peak and name=Point (height in feet))

[Andy Townsend]

On 21/03/2019 07:13, Paul Norman via Talk-us wrote:
As a maintainer of some of the projects listed, I find that you're 
misrepresenting the situation.


On 2019-03-08 11:25 a.m., Kevin Kenny wrote:

I've sounded out the maintainers of various of the OSM software, and
get different assessments.
osm2pgsql - Actively hostile to supporting what I need, contend that
osm2pgsql is the wrong tool for the job.


This is incorrect. Both maintainers have interest in adding 
functionality for propagating information from relations to ways - as 
opposed to from ways to relations, which is already supported. Neither 
of us have the free time to code it. If someone wanted to take this 
on, we'd help with the related issues like Lua API changes.


Other people (at least me) have also looked at doing it, but it's not 
straightforward.


I looked at it a while back to try and solve one of the issues that got 
merged into https://github.com/openstreetmap/osm2pgsql/issues/230 , but 
didn't get anywhere.  If part of 
https://github.com/openstreetmap/osm2pgsql/issues/901 was to improve the 
documentation in the code about how what's in the code actually worked 
(even if it didn't add much extra functionality) it'd be a great step 
forward.


Best Regards,

Andy



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

Re: [OSM-talk-fr] Des projets de construction pas sorti de terre !

[Vincent Bergeot]

Le 21/03/2019 à 10:24, Bernard Lefrançois a écrit :

//>/> Le 20.03.19 à 14:58, Vincent Bergeot a écrit : />/>> https://www.openstreetmap.org/user/L3mp1ck4 
/>>//>//>/>> https://www.openstreetmap.org/user/Dupuiche />//>//>/je penche pour une agence 
d'archi, le fait que les 2 se retrouve sur une />/même zone ! /On peut rajouter à la liste:
https://www.openstreetmap.org/user/Y43l//En plus d'introduire des éléments encore à l'état de 
projet, ils ont une tendance à cartographier "pour faire joli"/. /Avec, en 
particulier, un usage abusif du tag natural=tree par exemple comme 
ici://https://www.openstreetmap.org/#map=18/43.73203/7.27437=N//J'ai peine à 
croire que le contributeur a une source fiable pour la position et la hauteur de chaque arbre!


sans juger de la validité des arbres et la source pour les hauteurs 
(entre guillemet, c'est un "autre sujet"), cependant effectivement on 
retrouve juste à coté 
(https://www.openstreetmap.org/way/59923#map=19/43.73198/7.27412) le 
même utilisateur précédemment signalé, 
https://www.openstreetmap.org/user/Dupuiche avec des constructions non 
visibles en imagerie et en cadastre... et sans élément externe pour la 
source...


Donc

 * https://www.openstreetmap.org/user/Y43l
 * https://www.openstreetmap.org/user/Dupuiche
 * https://www.openstreetmap.org/user/L3mp1ck4

Et je viens d'être moins sympa : 
https://www.openstreetmap.org/changeset/68368951#map=19/49.00294/2.23289


à plus

--
Vincent Bergeot

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

Re: [talk-au] Platform names

[Sebastian S.]

If you believe Wikipedia 
http://en.wikipedia.org/wiki/Central_railway_station%2C_Sydney
The stations name is 'Central railway station' but it goes by many colloquial 
names.

I don't like the way the platforms are named currently. "Platform 8+9 (8;9)" is 
surely not the name on the signboards. I am in favour of splitting the 
platforms to have each number just called "Platform $". Maybe you can also 
indicated on which side 8 and 9 is in relation to a path which you would walk 
into the platform.

Maybe name:left=Platform 8 makes sense?

Another question I have is how would you route a blind person to and onto the 
platform when there is no way?
What about segment indicators. I have not been to central station but I assume 
for long trains there are segment indicators along the platform for passengers 
to find they carriages quicker. Are you planning to mapping these?
Have you looked at other train station in OSM?
I suggest to have a look at 
Hamburg  
https://www.openstreetmap.org/?mlat=53.552778=10.006389=15#map=18/53.55274/10.00677
Or Cologne https://www.openstreetmap.org/#map=18/50.94319/6.95853
Or Paris Gare du Nord https://www.openstreetmap.org/#map=17/48.88156/2.35623
Or London Kings Cross https://www.openstreetmap.org/#map=18/51.53194/-0.12326
Regards Sebastian
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

On 21 March 2019 11:26:39 am AEDT, Thomas Manson  
wrote:
>Looking at Central Station, Sydney, the platform names are things like
>'Platform 4+5'. (https://www.openstreetmap.org/relation/6015392)
>
>
>From my reading of
>https://wiki.openstreetmap.org/wiki/Tag%3Apublic_transport%3Dplatform,
>this should be
>the name of the station , so in this case that would be either Central
>or Central Station, with the platform numbers as the ref tag (which is
>already populated).
>
>1) First of all, is my understanding correct? It should be the station
>name.
>2) Secondly, should the name be Central or Central Station (assuming 1
>is correct)?
>
>Regards,
>Thomas
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

[OSM-talk-fr] Attribution... Rire ou pleurer ?

[Jacques Lavignotte]

Bonjour,


https://i.postimg.cc/WpDxMbxP/Screenshot-2019-03-21-11-56-25-796-com-twitter-android.jpg


Ici pour leur expliquer :

https://twitter.com/centre_presse/status/1108324286647943173

J.

--
GnuPg : C8F5B1E3 Because privacy matters.


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

Re: [OSM-talk-fr] Des projets de construction pas sorti de terre !

[Leroy Olivier]

>
> en voyant la distribution non régulière des arbres,
> je n'ai pas l'impression que c'est une exploitation forestière.
> généralement les arbres sont en rangée ultra alignée-artificielle
> afin de faciliter leur futur abatage


L'exploitation forestière c'est l’ensemble des processus qui vont de
l'arbre sur pied à sa première transformation. Ce que tu décris c'est un
type de sylviculture très fortement influencé par des machines de
l'exploitation forestière mais dans le cadre de feuillus en traitement
régulier ou de tous en irrégulier tu peux très bien avoir une exploitation
forestière sans que cela se "voit". D'autant qu'une opération est courte
dans le temps et même les layons d'exploitations peuvent vite être masqué.

je vois pas le soucis.
>

Moi non plus, d'où ma question sur une bonne pratique (ou pas). A priori de
ce que j'ai retenu la présence d'une node taggé "d'arbre isolé" dans une
parcelle forestière (j'en profite pour dire qu'une parcelle forestière n'ai
pas nécessairement liée à une exploitation, ce qui était peut être l'objet
de quiproquo) est réservé dans le cadre d'arbre particulier, remarquable ou
qui apporte une information en plus que le landuse. Est ce toujours le cas ?

Le jeu. 21 mars 2019 à 11:28, marc marc  a
écrit :

> Le 21.03.19 à 11:12, Leroy Olivier a écrit :
> > l'information de leur hauteur est de source compatible avec osm
> > alors je vois pas pq elles n'ont pas leur place dans osm
> > et encore moins comment est-ce que la hauteur d'un arbre pourrait
> être
> > transformé en un landuse
> >
> > La hauteur a tout a fait sa place pour un arbre isolé, la question est
> > de savoir si elle a sa place dans le cadre d'une parcelle forestière
>
> en voyant la distribution non régulière des arbres,
> je n'ai pas l'impression que c'est une exploitation forestière.
> généralement les arbres sont en rangée ultra alignée-artificielle
> afin de faciliter leur futur abatage
>
> > n'est ce pas plus sage cartographier ce paquet d'arbre comme un landuse ?
>
> je n'aurais pas rentré le détail de chaque arbre mais si quelqu'un le
> fait, je vois pas le soucis.
>
> > cela ne marchera pas bien en dehors de ce cas.
>
> on semble bien être en dehors du cas d'une exploitation forestière
> https://www.openstreetmap.org/node/5736145028
> j'imagine que pc = permis de construire
> reste à savoir si ces hauteurs ont réellement été mesurée ou au moins
> estimée ou si c'est pure invention pour faire joli sur un rendu 3d
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 
Olivier Leroy
Docteur Géographie et Environnement
Post-doctorant EVS ANR Rêveries 
06.18.37.18.08
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Des projets de construction pas sorti de terre !

[marc marc]

Le 21.03.19 à 11:12, Leroy Olivier a écrit :
> l'information de leur hauteur est de source compatible avec osm
> alors je vois pas pq elles n'ont pas leur place dans osm
> et encore moins comment est-ce que la hauteur d'un arbre pourrait être
> transformé en un landuse
> 
> La hauteur a tout a fait sa place pour un arbre isolé, la question est 
> de savoir si elle a sa place dans le cadre d'une parcelle forestière

en voyant la distribution non régulière des arbres,
je n'ai pas l'impression que c'est une exploitation forestière.
généralement les arbres sont en rangée ultra alignée-artificielle
afin de faciliter leur futur abatage

> n'est ce pas plus sage cartographier ce paquet d'arbre comme un landuse ?

je n'aurais pas rentré le détail de chaque arbre mais si quelqu'un le 
fait, je vois pas le soucis.

> cela ne marchera pas bien en dehors de ce cas.

on semble bien être en dehors du cas d'une exploitation forestière
https://www.openstreetmap.org/node/5736145028
j'imagine que pc = permis de construire
reste à savoir si ces hauteurs ont réellement été mesurée ou au moins 
estimée ou si c'est pure invention pour faire joli sur un rendu 3d
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-de] Overpass API wegen Upload-Filtern temporär aus

[dktue]

Super, dass eine weiterhin funktionstüchtige Alternative eingerichtet 
wurde -- leider erhalte ich dort aber nur einen 403-Fehler. Ist da 
eventuell ein Konfigurationsfehler drin?


Am 21.03.2019 um 05:26 schrieb Roland Olbricht:

Hallo zusammen,

am 26. März soll das EU-Parlament über eine Urheberrechtsreform
abstimmen, die als Seiteneffekt unter anderem OpenStreetMap gefährdet.
Details siehe
https://www.openstreetmap.de/uf/

Um alle Nutzer auf die Möglichkeiten zu Protesten hinzuweisen, schließen
sich mehrere OSM-Dienste einschließlich der Overpass API dem heutigen
Aktionstag an. Bei der Overpass API dauert die Unterbrechung bis ca. 
21 Uhr.


Nutzer, die statt der normalen Suchergebnisse das Informationsergebnis
sehen, können die URL temporär auf
https://overpass-api.de/no_art11art13/
ändern. Diese temporäre URL wird dann mit der Wiederherstellung des
normalen Betriebs wieder abgeschaltet.

Ich bedauere die Unannehmlichkeiten, erinnere aber daran, dass dies der
Vermeidung weitaus größerer Unannehmlichkeiten dient.

Viele Grüße,

Roland

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



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

Re: [Talk-us] Proposed mechanical edit - remove objects that are not existing according to source of GNIS import that added them

[Mike N]

On 3/21/2019 3:04 AM, Mateusz Konieczny wrote:
What is the benefit, during survey, of mapped places that are not 
existing anymore?


I encounter many during surveys (usually result of data getting 
outdated) and for me it was
always time sink (as I needed to check is it actually gone) and never 
useful in any way.


Note that it is not obvious, especially for beginner or data users, that 
all of this places

are not existing anymore.


 This has been my experience as well when methodically reviewing 
several hundred GNIS nodes around here.   Everyone is fond of pointing 
out where GNIS is poorly located or out of date, but every GNIS object 
identified as (historical) was 100% accurate.   Let's reserve mapper 
labor and MapRoulette projects for those that benefit from human review. 
 This project would qualify for automated intervention.


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

Re: [OSM-talk-fr] Des projets de construction pas sorti de terre !

[Leroy Olivier]

>
> l'information de leur hauteur est de source compatible avec osm
> alors je vois pas pq elles n'ont pas leur place dans osm
> et encore moins comment est-ce que la hauteur d'un arbre pourrait être
> transformé en un landuse


La hauteur a tout a fait sa place pour un arbre isolé, la question est de
savoir si elle a sa place dans le cadre d'une parcelle forestière
(landuse). Dans le cas cité n'est ce pas plus sage cartographier ce paquet
d'arbre comme un landuse ?
Concernant la hauteur dans le cadre d'une parcelle (sens forestier) avec
des arbres de même age les hauteurs sont proches et  assez homogènes pour
utiliser une moyenne mais cela ne marchera pas bien en dehors de ce cas.

J'espère que c'est plus clair.

Olivier

Le jeu. 21 mars 2019 à 10:58, marc marc  a
écrit :

> Le 21.03.19 à 10:49, Leroy Olivier a écrit :
> > (https://www.openstreetmap.org/#map=18/43.73203/7.27437=N), les
> > hauteurs varient et on a pas l’espèce ce qui en fait un cas plus étrange
> > : les hauteurs ne semblent pas mauvaises donc est ce que c'est pas "un
> > projet étudiant" ou un teste de mesure via un drone ou un LIDAR ? Après
> > oui pourquoi  le mettre dans OSM et si il faut le mettre pourquoi pas
> > plutôt avec un landuse ?
>
> Si :
> - ces arbres existent vraiment
> - l'information de leur hauteur est de source compatible avec osm
> alors je vois pas pq elles n'ont pas leur place dans osm
> et encore moins comment est-ce que la hauteur d'un arbre pourrait être
> transformé en un landuse
> La seule chose c'est que les arbres ne sont pas immuable et que donc
> dans 20 ans, la mesure aura perdu de sa précision par rapport à la réalité.
>
> faudrait regarder le changeset pour voir si une source est déclarée
> et/ou demander au contributeur
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 
Olivier Leroy
Docteur Géographie et Environnement
Post-doctorant EVS ANR Rêveries 
06.18.37.18.08
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Des projets de construction pas sorti de terre !

[marc marc]

Le 21.03.19 à 10:49, Leroy Olivier a écrit :
> (https://www.openstreetmap.org/#map=18/43.73203/7.27437=N), les 
> hauteurs varient et on a pas l’espèce ce qui en fait un cas plus étrange 
> : les hauteurs ne semblent pas mauvaises donc est ce que c'est pas "un 
> projet étudiant" ou un teste de mesure via un drone ou un LIDAR ? Après 
> oui pourquoi  le mettre dans OSM et si il faut le mettre pourquoi pas 
> plutôt avec un landuse ?

Si :
- ces arbres existent vraiment
- l'information de leur hauteur est de source compatible avec osm
alors je vois pas pq elles n'ont pas leur place dans osm
et encore moins comment est-ce que la hauteur d'un arbre pourrait être 
transformé en un landuse
La seule chose c'est que les arbres ne sont pas immuable et que donc 
dans 20 ans, la mesure aura perdu de sa précision par rapport à la réalité.

faudrait regarder le changeset pour voir si une source est déclarée
et/ou demander au contributeur
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Des projets de construction pas sorti de terre !

[Leroy Olivier]

Merci pour les partages,

J'ai mis de coté le deux cas avec des arbres isolés. Dans le premier (celui
près d’Orléans : https://www.openstreetmap.org/#map=13/47.9524/1.8608) tous
les arbres font 6 m de hauteur, cela ressemble plus à un import d'un
logiciel d'archi qui a besoin de la hauteur pour un rendu. Dans le second (
https://www.openstreetmap.org/#map=18/43.73203/7.27437=N), les
hauteurs varient et on a pas l’espèce ce qui en fait un cas plus étrange :
les hauteurs ne semblent pas mauvaises donc est ce que c'est pas "un projet
étudiant" ou un teste de mesure via un drone ou un LIDAR ? Après oui
pourquoi  le mettre dans OSM et si il faut le mettre pourquoi pas plutôt
avec un landuse ?

Olivier



Le jeu. 21 mars 2019 à 10:25, Bernard Lefrançois 
a écrit :

> >* > Le 20.03.19 à 14:58, Vincent Bergeot a écrit :
> *>* >> https://www.openstreetmap.org/user/L3mp1ck4 
> 
> *> >>>* >> https://www.openstreetmap.org/user/Dupuiche 
> 
> *>>>* je penche pour une agence d'archi, le fait que les 2 se retrouve sur une
> *>* même zone !
>
> *On peut rajouter à la liste:https://www.openstreetmap.org/user/Y43l
> En plus d'introduire des éléments encore à l'état de projet, ils ont une 
> tendance à cartographier "pour faire joli"*.
> *Avec, en particulier, un usage abusif du tag natural=tree par exemple comme 
> ici:https://www.openstreetmap.org/#map=18/43.73203/7.27437=NJ'ai peine 
> à croire que le contributeur a une source fiable pour la position et la 
> hauteur de chaque arbre!
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 
Olivier Leroy
Docteur Géographie et Environnement
Post-doctorant EVS ANR Rêveries 
06.18.37.18.08
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Des projets de construction pas sorti de terre !

[Bernard Lefrançois]

//>/> Le 20.03.19 à 14:58, Vincent Bergeot a écrit : />/>> https://www.openstreetmap.org/user/L3mp1ck4 
/>>//>//>/>> https://www.openstreetmap.org/user/Dupuiche />//>//>/je penche pour une agence 
d'archi, le fait que les 2 se retrouve sur une />/même zone ! /On peut rajouter à la liste:
https://www.openstreetmap.org/user/Y43l//En plus d'introduire des éléments encore à l'état de 
projet, ils ont une tendance à cartographier "pour faire joli"/. /Avec, en 
particulier, un usage abusif du tag natural=tree par exemple comme 
ici://https://www.openstreetmap.org/#map=18/43.73203/7.27437=N//J'ai peine à 
croire que le contributeur a une source fiable pour la position et la hauteur de chaque arbre!
//

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

Re: [OSM-talk-fr] Doubles adressages (entrée de rue, bâtiment)

[marc marc]

Le 21.03.19 à 09:34, Jérôme Seigneuret a écrit :
> consensus

hélas non

> Sur le bâti j'en vois pas vraiment l'intérêt...

cfr la discussion précédente :)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [talk-au] Platform names

[Sebastian S.]

Yes there is a tag for short name. Don't know at the moment but is listed in 
the wiki under the names site.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

On 21 March 2019 6:40:25 pm AEDT, Warin <61sundow...@gmail.com> wrote:
>On 21/03/19 15:42, Andrew Davidson wrote:
>> On 21/3/19 11:26, Thomas Manson wrote:
>>> 1) First of all, is my understanding correct? It should be the 
>>> station name.
>>
>> Depends on which version you'd like to believe. The original proposal
>
>> for public_transport=platform 
>> (https://wiki.openstreetmap.org/w/index.php?oldid=625726#Platform)
>said:
>>
>> "The name by which the platform is known."
>>
>> someone has later decided to change this. Which one is "correct"?
>When 
>> using PTv2 I stick to just the original proposal description as the 
>> various "translations" has made it harder and harder to understand
>(in 
>> other words the platform name is fine).
>>
>> However, I'd split them into single platforms, there's no need to 
>> combine them.
>
>+ 1
>Split the platforms if possible/convenient and you have time.
>The train arrives at/departs from platform 4 ... not platform 4+5.
>
>Central or 'Central Station' refers to the whole thing. When you are 
>there you talk of 'platform 5' not 'Central Station Platform 5' .. so 
>I'd stick with just the platform as the name - locally that is what is 
>used.
>Same with other stations.
>
>
>>
>>> 2) Secondly, should the name be Central or Central Station (assuming
>
>>> 1 is correct)?
>>
>> Central is the short name, Central Station is the full name. 
>
>Not certain if OSM has short_name .. if not I'd use local_name.
>
>___
>Talk-au mailing list
>Talk-au@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-au
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

[OSM-talk-fr] Doubles adressages (entrée de rue, bâtiment)

[Jérôme Seigneuret]

Bonjour,

Je ressors encore le sujet pour savoir si je peux faire du ménage.

A-t-on revu les règles pour l'adressage afin d'améliorer les choix. Définir
un consensus pour éviter la saisie de double adresses?

Entrée, batiment, résidence ...

Par défaut je met à l'entrée du portail et sinon à l'entrée de la maison.
entrance=main ou barrier=gate

Sur le bâti j'en vois pas vraiment l'intérêt...

Jérôme
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-ie] Validator of Wikipedia and Wikidata links in Ireland

[Mateusz Konieczny]

Mar 20, 2019, 1:24 PM by a...@pigsonthewing.org.uk:

> On Tue, 19 Mar 2019 at 18:12, Mateusz Konieczny <> matkoni...@tutanota.com 
> > > wrote:
>
>> Mar 19, 2019, 5:04 PM by >> a...@pigsonthewing.org.uk 
>> >> :
>>
>> > Can you do this outside Ireland also?
>>
>> Are you interested in Ireland, part of the Ireland or some other part of the 
>> world?
>>
>
> I'm in the UK (so please do that), but have a global interest in
> improving OSM/Wikidata+Wikipedia integration.
>
https://matkoniecz.github.io/OSM-wikipedia-tag-validator-reports/ 

For now just Dublin is added but it has some things to fix.
So for start it should be enough.

Let me know if there are some false positives or if report can be presented in
way making using it easier/more efficient.

>> (in fact this bot edit is result of project that was about listing invalid
>> wikipedia and wikidata tags).
>>
>
> Is that documented, please?
>
Wikipedia tag validator code is published at 
https://github.com/matkoniecz/OSM-wikipedia-tag-validator
but it is not too useful as part of its dependencies is not published
(open an issue on Github if you are interested in using the code, 
it will increase chance that I will focus on this project)
___
Talk-ie mailing list
Talk-ie@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ie

Re: [talk-au] Platform names

[Warin]

On 21/03/19 15:42, Andrew Davidson wrote:

On 21/3/19 11:26, Thomas Manson wrote:
1) First of all, is my understanding correct? It should be the 
station name.


Depends on which version you'd like to believe. The original proposal 
for public_transport=platform 
(https://wiki.openstreetmap.org/w/index.php?oldid=625726#Platform) said:


"The name by which the platform is known."

someone has later decided to change this. Which one is "correct"? When 
using PTv2 I stick to just the original proposal description as the 
various "translations" has made it harder and harder to understand (in 
other words the platform name is fine).


However, I'd split them into single platforms, there's no need to 
combine them.


+ 1
Split the platforms if possible/convenient and you have time.
The train arrives at/departs from platform 4 ... not platform 4+5.

Central or 'Central Station' refers to the whole thing. When you are 
there you talk of 'platform 5' not 'Central Station Platform 5' .. so 
I'd stick with just the platform as the name - locally that is what is 
used.

Same with other stations.




2) Secondly, should the name be Central or Central Station (assuming 
1 is correct)?


Central is the short name, Central Station is the full name. 


Not certain if OSM has short_name .. if not I'd use local_name.

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

Re: [Talk-us] US map rendering (Was: Re: Spot elevations collected as natural=peak and name=Point (height in feet))

[Paul Norman via Talk-us]

As a maintainer of some of the projects listed, I find that you're 
misrepresenting the situation.


On 2019-03-08 11:25 a.m., Kevin Kenny wrote:

I've sounded out the maintainers of various of the OSM software, and
get different assessments.
osm2pgsql - Actively hostile to supporting what I need, contend that
osm2pgsql is the wrong tool for the job.


This is incorrect. Both maintainers have interest in adding 
functionality for propagating information from relations to ways - as 
opposed to from ways to relations, which is already supported. Neither 
of us have the free time to code it. If someone wanted to take this on, 
we'd help with the related issues like Lua API changes.



OSM Carto - Little interest, but that's because of the emphasis on
consistent rendering worldwide, and this is really a project specific
to North America.


Pictorial road shields require rendering ref from route relations, and 
that is not an easy problem to solve. I'm on record as doubting it can 
be solved given the technical and cartographic constraints the style 
faces. Allowing propagation of information from relations to ways would 
change that.


It sucks to hear that it won't be implemented without someone stepping 
forward with pull requests, but that's the reality of the situation.



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

Re: [Talk-us] Gated communities

[Mateusz Konieczny]

access=destination for inner ways for community may be also a good idea
to give data to routers that transit traffic is not allowed (or access=private
if there is limited or no public access at all).

Though routers will use that only if there is more than one gate.

As usual - additional bicycle=*, foot=*, vehicle=*, emergency=* etc may apply.

For example some gates may have access used by emergency vehicles, allowing
them to open it and go through. Though tagging it is possible in cases where it 
is
signed.

Mar 21, 2019, 4:36 AM by ba...@ursamundi.org:

> I like this answer.  Behind the gates I tend to tag as private, but giving 
> one of the barriers access=destination should be enough for that to be the 
> default answer for going in, if implemented.
>
> Not really something common in Oklahoma, usually gated communities have only 
> one way in or out that isn't an emergency access, pedestrian or bicycle only 
> gate.
>
> On Wed, Mar 20, 2019 at 7:24 PM Evan Derickson <> derickso...@gmail.com 
> > > wrote:
>
>> What about marking the resident-only gates with access=private and the guest 
>> gate as access=destination?
>>
>> On Wed, Mar 20, 2019, 16:03 Eric H. Christensen via Talk-us <>> 
>> talk-us@openstreetmap.org >> > wrote:
>>
>>> -BEGIN PGP SIGNED MESSAGE-
>>>  Hash: SHA256
>>>  
>>>  ‐‐‐ Original Message ‐‐‐
>>>  On Wednesday, March 20, 2019 6:38 PM, Frederik Ramm <>>> 
>>> frede...@remote.org  wrote:
>>>  
>>>  > Should all roads inside the gated community be access=private?
>>>  
>>>  I wouldn't necessarily mark all the roads as private as I think that would 
>>> hinder the routing engines.
>>>  
>>>  > What tags should be applied to (a) the main gate where visitors and
>>>  > delivery services are expected to report, and (b) resident-only gates?
>>>  
>>>  I've mapped a neighborhood like this before and I think I got the routing 
>>> to work properly by using gates at non-manned areas with access=private and 
>>> something else at the guard houses with access=designated or something to 
>>> that affect.  I think that fits the model...
>>>  
>>>  Eric "Sparks"
>>>  -BEGIN PGP SIGNATURE-
>>>  Version: ProtonMail
>>>  Comment: >>> https://protonmail.com 
>>>  
>>>  wsFcBAEBCAAGBQJcksYxAAoJEIB2q94CS7PREZoQALxqnyFgf57KuZ8btd9G
>>>  Rh/ttSnL2ut/P3JBddk++vM3qvxD0N6dAEQDF5X1mMYvYtwkjJ3JUm5WeFSL
>>>  MTt3teOV1KIJWb7fk8VsysJUatz3Q3Ksty9fevG1t5W2l+9tkXn6eNzMIL5c
>>>  Ztdabtgrlx/6I04IpQnPcqAjJUh48g5aQYCitfMQf3A/67/CRt0YnsYEa/79
>>>  0WmOUmtxLSDdofwOwi3g6CCma6oWiAttnrCfHLQhqbALSlM9e0+VLGICT2ma
>>>  c3eV0tzE7qvv6Xw3ngos6uVwsnJ5ppnslBax+ZDyRlc5De0ka+XAep/VWJQc
>>>  oU5Yd6gYj+7xiP+loFRLQoOR2gPSf1C/nPIVBKiD0tWgiEkPK/zHA8jA6C83
>>>  a+ZR+BNZ5LXQsSbHGn/4R5jyXBmRSRlsQ3UajVfcaDOteRKsvW2zNQUxQJn/
>>>  uzCPE6H1ZkuMjNzr2qT4/IT8TXc8Qyx+rZB/q0OiJfFa1QofNOmy9rsXkxzm
>>>  bDdcH+swBAe6eXz1snM/hYW8HDn0aba/TPYCK5+q5B3D9ynrIH9HktPVcIs9
>>>  wbt4/+qhBe4bxihA5A2vntZyrQJeHqObiMHvN8a4Zs1AiMvzEw70JAth6uYo
>>>  0oNrFCnHC3GZrEHZzyyGK/pjKlcevupEn4NIUZvWO1T6ph3rMLiAr241eSSy
>>>  xykO
>>>  =y2bt
>>>  -END PGP SIGNATURE-
>>>  
>>>  
>>>  ___
>>>  Talk-us mailing list
>>>  >>> Talk-us@openstreetmap.org 
>>>  >>> https://lists.openstreetmap.org/listinfo/talk-us 
>>> 
>>>
>> -- 
>>
>>
>> --
>>  Evan Derickson
>>  (360) 402-6494
>>
>>
>> ___
>>  Talk-us mailing list
>>  >> Talk-us@openstreetmap.org 
>>  >> https://lists.openstreetmap.org/listinfo/talk-us 
>> 
>>

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

Re: [Talk-us] Proposed mechanical edit - remove objects that are not existing according to source of GNIS import that added them

[Mateusz Konieczny]

Mar 21, 2019, 4:46 AM by m...@rtijn.org:

>
>
>> On Mar 20, 2019, at 9:01 AM, Mateusz Konieczny <>> matkoni...@tutanota.com 
>> >> > wrote:
>>
>> I plan to run an automated edit that will revert part of the GNIS
>> import that added them and delete objects that never had any reason to
>> appear in the OSM database in any form, at least according to GNIS data.
>>
>> Please comment no matter what you think about this idea! I will not
>> make the edit without a clear support so please comment if you think
>> that it is a good idea and if you think that it should not be done.>>  
>>
>
> Thanks for bringing the idea up. It actually did come up fairly recently on 
> Slack > https://osmus.slack.com/archives/C029HV951/p1550176430103000 
> >  
>
> My view is that we would be missing an opportunity to have mappers review 
> these locations and update the areas concerned. These nodes exist mostly in 
> ‘undermapped' / remote areas that could use some human mapper attention. So 
> I’d be in favor of trying to resolve this using some human driven cleanup 
> first.
>
What is the benefit, during survey, of mapped places that are not existing 
anymore?

I encounter many during surveys (usually result of data getting outdated) and 
for me it was
always time sink (as I needed to check is it actually gone) and never useful in 
any way.

Note that it is not obvious, especially for beginner or data users, that all of 
this places
are not existing anymore.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [OSM-talk-fr] Des projets de construction pas sorti de terre !

[Jean-Claude Repetto]

Le 21/03/2019 à 00:22, Sébastien Dinot a écrit :


J'ai eu par ailleurs un problème similaire en septembre 2017 avec un
autre contributeur, qui avait tracé des routes et des passages
souterrains qui, à cette heure, n'existent toujours pas. Il leur avait
même affecté un nom (probablement celui prévu, mais nous verrons bien le
jour où ces rues existeront). Le contributeur n'a jamais répondu à mes
messages. J'ai fini par tout effacer moi-même car ces tracés induisaient
méchamment en erreur les outils de routage. Ce contributeur était :

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

Sébastien



Bonjour,

Au lieu de tout effacer, il est préférable d'ajouter le préfixe proposed:
https://wiki.openstreetmap.org/wiki/Lifecycle_prefix

Jean-Claude

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

Re: [Talk-us] Gated communities

[Mateusz Konieczny]

Mar 20, 2019, 11:38 PM by frede...@remote.org:

> Hi,
>
> DWG have been contacted by a resident of a gated community in Florida.
> They were unhappy about our routing which apparently leads people
> through an unmanned "residents only" gate where they won't get in,
> instead of to the manned main gate.
>
> I wonder how to deal with this, firstly from a "what is correct on the
> ground" perspective, but then also from a "what is useful routing-wise"
> perspective.
>
> Should all roads inside the gated community be access=private?
>
> What tags should be applied to (a) the main gate where visitors and
> delivery services are expected to report, and (b) resident-only gates?
>
> Bye
> Frederik
>
It depends on gated community.

For start, "residents only" gate is for me clearly access=private.

"manned main gate" - is access strongly restricted?
If nearly everybody, including vehicles, is let in I would tag it access=yes.
It would also mean that access=destination would be better than access=private
for inner ways of community.

If access is strongly filtered (entrance requires permission from resident or
guard is likely to resuse) then I would tag both gates access=private.
Though it means that these gates are again not distinguishable.

In Poland many gated communities are blocking only cars (to protect
limited parking space) so I tag it as
vehicle=private, bicycle=yes
as both pedestrians and cyclists are let in by guards without restriction.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[OSM-talk-fr] Overpass API en grève

[Roland Olbricht]

Bonjour,

le Parlement européen va voter la Proposition de directive sur le droit
d'auteur dans le marché unique numérique. Cette proposition menace
l'existence d'OpenStreetMap par des affaires juridiques tres cheres.

Les articles problematiques sont article 11 et article 13.
Un loi comme article 11 existe déja en Allemagne et Espagne.
Il a étouffé plusieur services du net en Allemagne et plusieurs éditeurs
en Espange parce-que les côut juridiques sont insurmontable pour tous
que de services très grandes et ils n'ont pas la force pour un
negotiation favorable.

Pour informer tous le monde, le service Overpass API est parmi autres
services en grève tojour jusq'au 21h (soit 20h UTC).

Si vous devez obentir des résultats normales, changez le URL a
https://overpass-api.de/no_art11art13/
Cette URL reste disponible jusq'au fin de grève cette soir.

Je suis desolée pour les désagréments. Ces sont necessaires pour avenir
de désagréments graves et permanents.

Roland

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