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

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

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: [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: [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: [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-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: [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: [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: [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