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

[Jmapb]

On 12/9/2020 2:34 PM, Maarten Deen wrote:

If you can not make an analogy then conversation and discussion is
lost and I do not see how this comment would degrade women.


Many in the world have the good fortune to live lives where the constant
threat of sexual assault is not an issue. To them, Trump's boasts may
seem offensive but also slightly absurd, and even weak.

Many others in the world are survivors of sexual violence. Many are
enduring it on a daily basis. To them, casual description of sexual
violence just to make a point -- even quoted, even as an analogy -- is
problematic.

Like you, I've personally seen no "systemic aggressive behaviour" in the
OSM community -- but I'll take seriously anyone who has.

Jason




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

Re: [Talk-us] Recent Trunk road edits

[Jmapb]

On 9/28/2020 10:10 PM, Albert Pundt wrote:

It seems another editor by the name of Fluffy89502 is going around
doing similar edits all over the US, even demoting divided, multi-lane
roads. Other users have commented on his changesets and he cites the
wiki's wording.


Yeah when I saw this topic I assumed it was going to be about Fluffy.
Very different attitude than "floridaeditor" though, see
https://www.openstreetmap.org/changeset/88278035

J


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

Re: [Talk-us] Marking structure as damaged or condemned

[Jmapb via Talk-us]

On 8/5/2020 9:11 PM, Eric H. Christensen via Talk-us wrote:

Tropical Storm Isaias left several homes in my neighborhood severely damaged 
and condemned.  Is there a proper way to map these structures?

Thanks,
Eric


Hi Eric, I've used building=ruins (
https://wiki.openstreetmap.org/wiki/Tag:building=ruins ) for situations
like this where the building in still present but observably no longer
functioning as a building.

Pros:
 - Documented in the wiki.
 - Supported by iD.
 - Building will still render on the default map.

Cons:
 - Information about building type, if it wasn't simply building=yes,
will be lost (thought it would be in the history of course, and could
still be added via another tag, eg, was:building=house.)
 - Some people have a slightly more romantic understanding of the word
"ruins" that doesn't include recently-condemned buildings.
 - Some people consider a lifecycle prefix like abandoned:building=yes
to be more elegant.
 - Don't tag for the renderer!

Regardless of the tag you choose, I agree with Dave that adding
something like "note=building ruined August 2020 by Hurricane Isaias,
currently condemned" would assist any armchair mappers using previous
years' imagery.

Good luck & stay safe, Jason


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

Re: [Talk-us] Interested in importing address points in New York State

[Jmapb]

HI Skyler, I'm also a NY mapper, welcome to the party!

You've probably gleaned by now that imports are a touchy subject in OSM.
Data license is part of the problem, since only the very most open of
open licenses are compatible with OSM. My assumption is that the NYS
address data will pass this test, but then there are additional
questions of accuracy, transformation, maintainability, and conflation
with the existing data.

One thing that jumps out right away -- importing addresses for all of NY
state is a gargantuan task. Most address imports on OSM will center
around a small area, maybe as large as a county, and even so the task
will generally be broken up into even smaller areas using a tasking
manager and imported gradually by a team, with a lot of manual scrutiny.
An address import for all of NY State would likely be a years-long,
project.

I also expect that data quality, both location and the address fields,
will vary in the extreme. There may be some portions of the state where
the data is entirely useless, or will do more harm than good. And
unfortunately, without local knowledge to consult, it can be difficult
to determine this ahead of time.

My advice would be to sketch out an import plan for a small community
you're familiar with, and see how that goes. You'll probably find that
some common assumptions about addresses are false at the edge cases. For
instance, you mention deduplicating by searching for existing elements
with matching addr:* tags. But I've frequently found a single address
applying to several buildings/properties, and the converse too of
course. Having different roads with the same name in close proximity is
also alarmingly common. Expect mismatches due to variance in street
names (Campbel Lane, Camp Bell Road, etc.)  or addresses currently
mapped with only a housenumber.

There are also many areas in NY where we have buildings mapped without
address tags. Ideally we'd want to add the address tags to the building
where appropriate, rather than just plop a new node somewhere in the
building's vicinity. This would almost certainly take a lot of manual
tweaking.

It's an exciting prospect to have good address data for the large
portions of the state that are relatively unmapped. I'll be happy to
assist with this project in whatever form it takes. For now I'm still
mapping addresses the old-fashioned way, by reading the numbers off of
mailboxes and front doors.

Good luck, Jason


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

Re: [Talk-us] access=private on driveways

[Jmapb]

On 7/14/2020 7:44 AM, Greg Troxel wrote:

Around me the norm is that residential driveways (98% of them) are not
signed no trespassing, but that it is considered reasonable to use them
if 1) you live there 2) you are delivering something 3) you are a guest
4) you are going there for some other reason widely considered legit,
like "I'm a new neightbor and saying hello".

It is not reasonable to just drive up them because you feel like it, get
out of your car, stand there for two minutes, get back in and leave.
That will typically result in someone calling the police.  If it were
access=yes, like a real road, that would still be odd, but not
actionable.

So I don't think access=permissive is proper for residential driveways
unless there is good reason to believe that.   It probably is a good fit
for private roads in neighborhoods that don't have a culture of no
trespassing signs where many people come and go.


I completely agree. Mappers should have a good and verifiable reason to
tag access=permissive on any road, and preferably they should record
what that reason is. I've seen situations where a driveway could
conceivably be tagged access=permissive, but it's rare.


As for access=private 'breaking' routing, this discussion feels very
much like tagging for the router, instead of tagging what is and fixing
the router.  If you are driving someplace and you have permission, then
it should be expected that you can use access=private ways to get to
your destination.  Humans konw this, and while most people wouldn't
randomly drive down other people's driveways, it's obvious that if you
are invited to a house it's ok to use their driveway.

So a router that does not allow use of access=private for a final
segment, by default, is broken.


Tagging for the router is definitely a cousin of tagging for the
renderer. But both the router and the renderer are useful for
maintaining map quality. If something breaks the default
openstreetmap.org map, it's worth some scrutiny. Same with something
that breaks OSRM.

And the full rule as I know it is "don't tag *incorrectly* for the
renderer." Ditto for the router. I would never suggest removing a
legitimate verifiable access=private tag just to make a particular route
work. But that doesn't mean that the router's behavior can't influence
tagging at all.


Suppose there is a house with a driveway that connects two roads with
the house in the middle, that's access=private.  A router should not use
that segment unless the destination is on that property.  That's why I
said that routers should allow a final segement of private, but not a
transition to private and a transition back.


This is the *exact* scenario that access=destination is designed for.
Routing software should allow a route to access=destination ways, but
never through them as a short cut.


Residential driveways around me are tagged access=private.  I think it's
wrong to change that.


And I feel exactly the same about access=private as I do about
access=permissive: Mappers should have a good and verifiable reason to
tag access=private on any road, and preferably they should record what
that reason is.

If mappers (or importers) have decided by fiat that all driveways should
be access=private, I believe they've done a disservice to the map and so
removing that tag is probably correct. If they're simply trying to
encode unsigned local law or custom, that's explicitly against the
community best practices. If they're pulling from a reliable
imports-list-approved open data source or tagging based on surveyed
signage, well then, high-fives all around.


I am really just saing that a driveway to a house should not be tagged
access=yes because a no trespassing sign cannot be seen.  That is a complete
violation of verfiability, becuase the mapper has zero evidence that
access should be yes.


Agreed. Mappers should have a good and verifiable reason to tag
access=yes. But don't conflate the absence of an access tag with an
explicit access=yes, even if software treats them the same.


B) the owner expects the normal social customs to be followed, of
useonly for invited guests, deliveries/etc. and actual neighborly
visits,and doesn't put a up a no trespassing sign because it's
prickly, notbecause they want random people doing random things ==>
access=private


Here we disagree. I believe access=private means permission is required
to legally use the way. Implied permission by social custom is not the
same thing. And in the real world, a driveway and a private road that
requires permission are very different. Those accustomed to ignoring the
"part of your route is on private roads" warning on their GPS because of
access=private driveways may find themselves in for a quite a shock when
they're confronted by an angry hunting club member on an access=private
road through the woods, where the public route would have taken 5
minutes longer if they hadn't turned left an hour ago but is now it's a
2-hour detour.


I can 

Re: [Talk-us] access=private on driveways (was: Deleting tiger:reviewed=no/addr:street for routes)

[Jmapb]

On 7/14/2020 4:53 AM, Mateusz Konieczny via Talk-us wrote:


Jul 14, 2020, 02:20 by jm...@gmx.com:

On 7/13/2020 4:09 PM, Matthew Woehlke wrote:

On 13/07/2020 15.16, Kevin Kenny wrote:


The immediate curtilage of a house is presumed to be
private; at least
in the US, one does not drive or walk directly up to
someone's house
without having business there. (Someone making a delivery,
obviously,
has business there.)


...this seems to be the definition of access=destination?


I'd say yes, that access=destination is closest to how I interpret
most
driveways: you can walk/drive along the driveway if you have a good
reason, eg to make a delivery or an inquiry.

access=destination mean "no transit", not "with valid reason".

access=destination on driveway means "cannot be used by transit",
not "can be used if owner presumably agrees".

access=destination has the same meaning as access=yes on ways
that are not usable for transit (for example driveway attached to
a single road on one end and leading into house)


Yes, I believe I understand the distinction here. (Which is why I said
"closest" -- it's not exactly right.)

By my understanding, access=destination means "You may use this way if
this is your destination." There are three implications here:
1 - It's more permissive than access=private. You don't need to ask to
use this way.
2 - It's less permissive than access=yes/permissive. You *only* have
permission if this is your destination. (I said "a good reason" which is
not exactly the same thing, though close.)
3 - You may not traverse this way onto another way with different
access, ie, don't use it for a shortcut. (A common road sign for this in
the USA is "No Thru Traffic".)

When a dead end like a driveway is tagged with access=destination,
number 3 is irrelevant and from a routing point of view it's identical
to access=yes/permissive. But numbers 1 and 2 still apply, so from a
semantic point of view it's a little better IMO.

But as I said, I would not encourage anyone to start tagging all
driveways with access=destination. I believe it's usually a better fit
than access=private, but unless there's specific prohibitive signage I'd
recommend omitting access tags on driveways.


If there was reason to believe you needed explicit permission to be on
that way, then access=private would be correct.

I am unsure what is the best way to tag "explicit permission not required,
implicit permission is required" case. (it is not a big problem in Poland
where nearly all such roads will have a gate anyway, bumping it
into access=private)


I'm really not sure how to interpret "Implicit permission is required."
To my mind, if permission is implicit, it's not required
(access=permissive) and if permission is required, it's not implicit
(access=private.)

For a typical unsigned & ungated driveway in the USA, I'd describe the
implied access as "You may use this way to make a delivery, or to
immediately ring the doorbell and state your business."
Access=destination is the closest tag IMO, but I think just
service=driveway and no access tag is better.

Jason

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

Re: [Talk-us] access=private on driveways (was: Deleting tiger:reviewed=no/addr:street for routes)

[Jmapb]

On 7/13/2020 3:22 PM, Tod Fitch wrote:

Out of curiosity, I looked at the tagging of a neighborhood I know of
which has privately owned roads (maintained by the homeowner’s
association) but no gate blocking entry. There are signs indicating
that the roads are “private” but that state road regulations are
enforced. The access on those roads is currently tagged as
access=permissive.

Thinking about it, that seems correct: The roads are privately owned.
But you are free to access them unless or until the owner withdraws
permission.

There are “gated communities” where you can’t get in unless you have a
card key or speak with a gate keeper. Those should, I think, have
access=private as you need explicit permission on each entry.

But for the case where the road is privately owned but the owner
allows access without prior consent, access=permissive seems to be a
good fit.

—Tod


Permissive sounds good to me in this case.

I suspect that sometimes access=permissive is applied in error by
mappers who misunderstand the term to mean "permission is required"
rather than "permission may be presumed."

To muddle things further, another popular tag is access=permit,
undocumented but I believe it means that access is allowed for holders
of a particular permit, eg, a camping permit or fishing license. If I'm
right about this then it's similar to access=private but a little more
informative.

And of course there's access=forestry, agricultural, military, delivery,
employees, customers -- all also a little more informative.

As usual I tag what I see, and if there's knowledge that can't easily be
observed firsthand then it's a good idea to be explicit about the source
and/or add a note=* tag. But I think this thread has made clear that
merely seeing the word "private" on a road sign does not mean the road
needs access=private.

Generally I'll use access=private for any road where the owner has
clearly prohibited unauthorized public access. A controlled physical
barrier isn't required but that would certainly qualify.

.Jason



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

Re: [Talk-us] access=private on driveways (was: Deleting tiger:reviewed=no/addr:street for routes)

[Jmapb]

On 7/13/2020 4:09 PM, Matthew Woehlke wrote:

On 13/07/2020 15.16, Kevin Kenny wrote:


The immediate curtilage of a house is presumed to be private; at least
in the US, one does not drive or walk directly up to someone's house
without having business there. (Someone making a delivery, obviously,
has business there.)


...this seems to be the definition of access=destination?


I'd say yes, that access=destination is closest to how I interpret most
driveways: you can walk/drive along the driveway if you have a good
reason, eg to make a delivery or an inquiry.

If there was reason to believe you needed explicit permission to be on
that way, then access=private would be correct. (And IMO someone
delivering to an address shouldn't automatically assume permission to
access a restricted way -- the ship-to address is not necessarily the
property of the person who requested the delivery.)


Is that the recommended way to tag residential driveways?

And I would say no, that tagging all driveways access=destination would
violate the traditional OSM best practice of "Don't map your local
legislation unless it's actually signed" (or however it's phrased.)
Unless there's a sign or some other indication (mapper's head on a
pike?) that this particular driveway has different access rules than
you'd expect, best to omit the access tag.




I haven't had any trouble getting OSMand to navigate to a house on a
road marked `access=private`. It pops up a warning that my destination
is on a private road, and asks whether it's OK to route over it - and
then does so happily.


My car does this, and doesn't even ask. It just warns me that "this
route uses private roads". I generally assume that's talking about the
final leg and ignore it.


I'm perfectly willing to believe that overzealous application of
'private' breaks _some_ routing engines, but 'breaks routing for
everyone' is a bit hyperbolic.


Yup.


Fair cop, I should have said "breaking routing for others" not "breaking
routing for everyone." I'm quite glad to hear that OSMAnd deals
gracefully with this problem, because no matter how much I retag and
finger-wag it will always be with us.


That said, it does seem like access=destination is more correct for
ways that aren't explicitly access-restricted?

Agreed, but I feel that in most cases, especially for driveways, the
access tag is better omitted. And regardless, the armchair tagging of
driveways as access=private strikes me as an error.

Jason

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

[Talk-us] access=private on driveways (was: Deleting tiger:reviewed=no/addr:street for routes)

[Jmapb]

On 7/13/2020 12:59 PM, Alex Hennings wrote:


The /sole purpose/ of routing is to get the user to their destination
without breaking any laws. These are also /specifically my/ /goals
/when I'm using a router. Frequently (in my rural area) getting to my
destination requires using a privately owned road. You might say
"access=private" isn't a problem because I can tell my router to
ignore "access=private". But I don't want to go down any roads that
say "Stay out" and have a gate, or a person brandishing a rifle.
When every privately owned road is marked as access=private, it is not
possible for me to achieve both of those goals (get there, don't break
laws) at the same time. By encouraging routers to ignore
"access=private" you're neutering real access restrictions.

So, you're either saying /don't worry about/ breaking laws, or /don't
worry about/ getting to your destination

That is my argument /against access=private/ on privately owned roads.
My argument /for ownership=private/ is to set a clear and visible
precedent that private ownership /has a tag/, which /is not the access
tag.
/

-Alex

(Trying once again to change this thread subject!)

I'm also in the "worry about it" camp.

To me, it's sad to see a mapper go to all the trouble of fixing the
routing to the house https://www.openstreetmap.org/way/263869602 by
drawing in the driveway https://www.openstreetmap.org/way/791633657 and
then snatching defeat from the jaws of victory by tagging the driveway
private. Yes, a large company like Amazon (who paid for this driveway to
be mapped, so we might presume it's mapped to their specifications) can
implement their own router and treat the access=private tags more
loosely, but that's no reason for them to be breaking routing for
everyone else.

In short, I think that driveways and other service roads should ONLY be
tagged access=private based on specific knowledge of a restriction. And
if the access restriction is not verifiable by survey, it's good to add
a access:source=* or note=* so mappers like me won't assume the tag is
outdated or erroneous.

And Kevin, relevant for hikers like you & me is the question of service
roads that lead to private enclaves within public lands. Often these
roads are public access up to a certain point, and having that
information correctly mapped is quite helpful. Many of these are
imported from TIGER with access=private the whole way, and reclaiming as
much of these as possible is certainly on my to-do list.

As far as what sign wording actually warrants access=private... "No
Trespassing", "Keep Out", that sort of thing. I agree that simply seeing
the word "private" does not equate to access=private, though in some
situations it would incline me towards access=destination. I wasn't
aware of ownership=private but I'll put it to use in the future.

Jason

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

[Talk-us] access=private on driveways (was: Deleting tiger:reviewed=no/addr:street for routes)

[Jmapb]

On 7/12/2020 6:03 PM, Mike Thompson wrote:

On Sun, Jul 12, 2020 at 10:28 AM Jmapb mailto:jm...@gmx.com>> wrote:

> The access -- somewhat common to find a pubic road imported with
access=private, so if I suspect this I'll leave the
> tiger:reviewed=no tag until access can be confirmed, and add a note
or fixme. (It's also quite common to find driveways
> imported as access=private. When surveying, I tend  to remove the
private tag if the driveway isn't gated or signed
> private, since access=private will prevent routing to the house at
the end of the driveway, sometimes even ending the
> route on a different residential road that's physically closer to
the house than the road the driveway's connected to.)
I always thought that driveways to private residences and private
roads (whether gated or not) should be tagged as access=private. 
Often these private roads are posted with a sign that says something
like "Private road, no trespassing", or "Private Road, Residents and
Guests Only."

Mike


As I said, I tend to remove access=private if I DON'T see any barrier or
signed restriction during a survey. If I see see "private" or "no
trespassing" I certainly wouldn't. This is consistent with OSM
verifiability standards.

I feel the most appropriate default tag for driveways would be
access=destination, but since generally they are short dead ends it
rarely seems necessary. But there do seem to be many driveways tagged
access=private. Some from TIGER (which certainly can't be trusted) and
some from humans, sometimes using Facebook's RapiD.

Here's an example of how access=private on a driveway causes the routing
problem I'm talking about:

https://www.openstreetmap.org/directions?engine=fossgis_osrm_car=41.9288%2C-74.0024%3B41.9157%2C-74.0290#map=16/41.9168/-74.0237=N

There's no access to the house at
https://www.openstreetmap.org/way/263869602 (forgive the poor building
mapping, not mine! ;) from Linderman Avenue. The correct is approach is
from the driveway https://www.openstreetmap.org/way/791633657 but that
driveway was marked as private by the mapper who added it (one of
Amazon's paid mappers, using RapiD.) The source list (always the same
long list of sources with the Amazon mappers) includes Bing Streetside
but I don't see any reason that this driveway should be marked private:

https://www.bing.com/maps?osid=fd2b22c5-aaed-46f5-8128-a64aaf15c84b=41.91594~-74.029559=19=106.782906=-7.023267=x=z.0=2=2=S00027

If I surveyed a location like this and deemed it appropriate to remove
the access=private tag from the driveway, I believe that would benefit
the map.

Jason

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

[Talk-us] Deleting tiger:reviewed=no/addr:street for routes (was: Streaming JOSM -- suggestions?)

[Jmapb]

On 7/9/2020 6:48 PM, Kevin Kenny wrote:

Personally, I think even that much is overkill for deleting tiger:reviewed.
I think that surface, lanes, and traffic controls are things that a
mapper can notice are not mapped, irrespective of the TIGER review
status. There are lots of hand-mapped roads that don't have the
information!

I'm willing to delete the tag when:

(1) I've checked alignment against two sets of aerials, at least one
with the leaves off. (In my case, that's almost always Maxar and NYS
Orthos Online.)
(2) I've added all bridges and culverts that I can identify on
aerials. (Which always leads me down the rabbit hole of mapping the
corresponding waterways)
(2) I've verified that the name matches the state DOT highway map and
the E911 address points.
(3) I've adjusted the road class (TIGER's 'residential' can mean
anything from a tertiary highway to a track!)
(4) I've created route relations if the road has a ref (and removed
the ref from the road's names!)

I don't do 'lanes' very often.  I do 'surface' if the road is
obviously not hard-surfaced (sometimes I can even see the ruts in
aerials), and I do traffic controls only when surveying in person,
which I always do afoot.

I'd like a way to indicate that an intersection is uncontrolled. I've
found myself returning on foot several times to the same intersection
to look for STOP signs that aren't there, because I can't remember
that I've checked it already.

The reason that I'm so lax is that in my part of the state, TIGER is
_horrible_ and mappers are scarce.  I chronically lack time to do very
much about it, although I've at least checked the above information
for all the unreviewed roads in my home county (barring some service
ways that I'm not sure I can access legally). I work intermittently on
a couple of neighbouring counties. There are a lot of service ways
'residential' ways in TIGER that are a mile or two off from the
correct alignment or are otherwise ridiculous. At this point, in my
area, 'tiger:reviewed=no' means 'beware: this road likely is entirely
hallucinatory' and I kill the tag once I've verified that the
information that TIGER provided is correct. The information that TIGER
didn't ordinarily provide, I can leave for others (possibly including
future-Kevin).


I've also been chipping away at TIGER junk in NY state (mostly Ulster
County) and I think my methodology's similar. I try to delete
tiger:reviewed=no if I'm reasonably confident that I've either confirmed
or fixed everything that the TIGER import has asserted about the road in
question, in particular:

 - The road geometry, which is often comically bad. I generally also
add the bridges and culverts (and get lost mapping streams back up into
the mountains) though I've never considered this necessary for deleting
tiger:reviewed=no. (Also, over time I've gotten a little bolder about
simply deleting the roads that don't seem to correspond to anything on
leaf-off satellite, Bing streetside, or the county maps -- especially
the ones that look like spiky stick drawings. I feel that leaving a road
I genuinely believe to be fictional is a disservice to the map.)

 - The highway=* classification -- most common problem I see here is
highway=residential for tracks, driveways, and other service roads (more
rarely residential for what should be secondary or tertiary.)

 - The access -- somewhat common to find a pubic road imported with
access=private, so if I suspect this I'll leave the tiger:reviewed=no
tag until access can be confirmed, and add a note or fixme. (It's also
quite common to find driveways imported as access=private. When
surveying, I tend to remove the private tag if the driveway isn't gated
or signed private, since access=private will prevent routing to the
house at the end of the driveway, sometimes even ending the route on a
different residential road that's physically closer to the house than
the road the driveway's connected to.)

 - The road name -- and this can be a real mess because road signs,
addresses, government maps, and TIGER often disagree. Even two road
signs a mile apart may disagree. I do my best to set name=* and
alt_name=*, and I'll often leave the extra fields from the TIGER import
(name_1, tiger:basename, etc) if they have other variations. Kevin, if
you can give some more details on your name-matching process using E911
and DOT maps, I'd love to learn.

Creating/repairing highway route relations is a special case of name
fixing I guess. I've been lax about removing TIGER's name=State Highway
X etc tags; I'll try to do better there.

Regarding the surface values, at some point Richard Fairhurst made the
specific request that adding surface=* should be part of the TIGER
cleanup, when possible. Personally I only tend to do it when the surface
can be clearly observed and the road in question falls somewhere in the
gap between paved residential and unpaved track. And I also don't
consider this necessary for deleting tiger:reviewed=no.

...Related 

Re: [Talk-us] How to map snowmobile trails in US?

[Jmapb]

On 5/7/2020 8:05 PM, Bob Gambrel wrote:

So imagine this simple example. A path (of some sort) goes from point
A to B. Between points B and C there is no way (no path, road,
highway, cycle way, foot path, track, etc. Then there is another path
of some sort between points C and D. So the relationship (a snowmobile
route) includes ways "AB", "BC" and "CD". What type of way should "BC"
be?

This area shows such a snowmobile trail:

https://www.openstreetmap.org/edit#map=17/45.83596/-95.31124

Much of it is not along any visible way of any sort. It looks like
part of it could be on an existing (but not mapped unpaved service
road) and part of it crosses a stream next to (but probably on) an
unmapped little bridge. If all the ways that were mappable were
actually mapped, most of the snomobile trail would still be on
unmapped (unmappable) "invisible in the summer" ways.


Best I know, these paths that only appear in the winter should be tagged
highway=path + seasonal=winter + snowmobile=yes/designated. Probably
also good to add foot=no and bicycle=no.

Of course they'll render year-round, and future mappers looking at
snowless aerial imagery might be inclined to delete them. So it would
probably be good to add a note that says "this path only appears in the
winter and is tagged accordingly, please do not delete based on aerial
imagery."

There's extremely limited use (literally 13 uses, all in Finland) of
seasonal:winter:highway=path. Putting the seasonality in a prefix would
allow you to avoid the troll tag aspect of highway=path +
seasonal=winter, but software support for this scheme is unlikely.

Asking on the tagging list is a good idea -- Talk-us is a bit of a ghost
town.

Jason


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

Re: [OSM-talk] Strava high resolution heatmap

[Jmapb via talk]

On 3/31/2020 7:26 AM, Volker Schmidt wrote:

Hi,
I am trying to find out at what point we sare with the Strava high-res
heatmap.
Forma a lagal point of view: can we use it for improving OSM?
If yes, how can we do that?
Unfortunately there is a lot of out-dated information around.


The latest I've heard is this thread from last November:

https://lists.openstreetmap.org/pipermail/talk/2019-November/083563.html

Rodrigo Davies at Strava says they "don't currently see a problem" with
using the heatmap for mapping. A screenshot of this communication was
added to the wiki at https://wiki.openstreetmap.org/wiki/Permissions/Strava

The wording falls short of a formal licensed release so personally I'm
not comfortable adding paths based on Strava data alone. But I've used
it to help with aligning aerial imagery, double-checking my own GPS
traces, and marking spots for further survey.

I probably wouldn't be comfortable adding paths based on Strava data
alone even if they did have an explicitly ODBL compatible license. Just
because there are GPS traces doesn't mean there's a path (plenty of
popular bushwacking routes in their data) and certainly doesn't tell me
what value to use for the highway key.

Jason


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

Re: [OSM-talk] Taking a break and a call for help

[Jmapb]

On 3/21/2020 10:37 AM, Dave F via talk wrote:

In my area, AL are adding legitimate data which helps improve the
quality of the OSM database. I believe they make the same amount of
errors as any other contributors, including experienced ones.

Unsure why he thinks OSMF should be keeping an eye on contributors
purely because they're paid.


IMO, it's not that they're *paid* per se but rather that there's a huge
army of them, all presumably with the same training and the same orders.
If those orders lead to bad mapping, it gets amplified greatly. This
also happens with organized groups of volunteer mappers.

Anecdotally, in my area, Amazon's drones are not a big problem but
occasionally they're pretty irksome. Sometimes they add hundreds of
service roads in a week, and generally very sloppily. They draw roads at
odd angles. They connect alleys that don't connect. They connect roads
to subways. They draw parking aisles like winding forest paths. They
distort the highways they connect to. They use outdated and misaligned
imagery. Once in a while they'll delete entire roads or buildings.

I try to keep an eye on them and fix the errors and the most egregious
road geometry. When I leave changeset comments, they generally reply,
but there are so many of them that it feels like trying to cook rice one
grain at a time.

Jason



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

Re: [OSM-talk] OSM is not the place for dissemination of authoritative data sets

[Jmapb]

On 3/19/2020 3:17 PM, Mikel Maron wrote:

> How would a mapper performing imports via RapiD comply with the
import guidelines?

By complying with the guidelines before setting up an import process
that leveraged RapiD for conflation.


That doesn't sound so bad to me, pending further details.

But it's not the first thing that leaps to mind when reading the blog
post, which claims that RapiD will allow imports by normal users who
find the traditional import process "too onerous." Current RapiD
workflow (in my experience) is "AI thinks a road/building is here and
looks like this. If you agree, click to add it." Changing the source
from AI-enhanced satellite imagery to "authoritative dataset" and I
picture a similar process: "Data Authority X thinks Y is here. If you
agree, click to add it." You can see how this sounds like an end-run
around the import guidelines, because it's performing an import without
a dedicated import account.

A good conflation tool would process a prospective dataset pre-import,
comparing OSM data against one or more external data sources and
assisting with other forms of data cleanup. If RapiD had a mode like
this, which allowed crowdsourced conflation instead of live map editing,
that could be useful.  The resulting (hopefully improved) dataset could
then be considered as a candidate for an import according to the
standard import guidelines. But offhand I imagine casual users would be
confused if the same piece of software is sometimes a live map editor,
and sometimes a pre-import conflation tool.

Jason

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

Re: [Talk-us] Updating opening_hours for COVID-19.

[Jmapb]

On 3/19/2020 10:43 AM, Eric H. Christensen via Talk-us wrote:

Sure, I get that. The flip side is that it is likely to get confusing
what is open and when with all the changes occurring. It would be good
to have a resource to help people determine where they can go if they
need something.


When interpreting opening_hours, software (and humans reading manually!)
should follow the LAST of semicolon-separated rules that matches a
particular datetime. So if you expect normal hours to resume at some
point, it's possible to encode temporary hours using exceptions appended
to the end of the value.

For example, a shop with "opening_hours=Mo-Fr 10:00-20:00" could be
retagged "opening_hours=Mo-Fr 10:00-20:00; 2020 Mar-May Mo-Fr 11:00-16:00".

Problems apparent offhand:
 - You have to pick an end date. Will "this all be over" by the end of
the year? End of the summer? Or do you want to recheck each POI every month?
 - No idea if any software actually correctly interprets adding years
as part of the date range, though it is part of the spec.
 - If hours are different for different days of the week, each weekday
or weekday range needs its own override. (Eg, opening_hours=Mo-Th
10:00-20:00; Fr 10:00-21:00; Sa 12:00-21:00; Su 12:00-20:00; 2020
Mar-May Mo-Th 11:00-16:00; 2020 Mar-May Fr 11:00-17:00; 2020 Mar-May Sa
12:00-17:00; 2020 Mar-May Su 12:00-16:00") The value can easily become
unwieldy bordering on absurd, and risks going over the 255 char limit.
 - Especially if the value is long and complex, it's hard for humans to
read. We don't tend to read through the entire list and look for
possible exceptions once we've found a match. Not to mention that no
other tag values in OSM use semicolons in this way. (We don't look at
"cuisine=italian;pizza" and think "This place serves pizza, which
overrides other Italian food, so don't go here for spaghetti".)

Jason


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

Re: [OSM-talk] OSM is not the place for dissemination of authoritative data sets

[Jmapb]

On 3/19/2020 7:57 AM, Mikel Maron wrote:

There is nothing here about circumventing our well defined import
guidelines, or disrespecting our basic tenets.


The blog post says "The process of creating an import is too onerous for
many users" and "Our hope is that RapiD can become a tool that’s simple
enough for anyone to import and verify new data sets."

How would a mapper performing imports via RapiD comply with the import
guidelines?

Jason

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

Re: [OSM-talk] Proposed new status for tags in the wiki: "import" for undiscussed tags that were only used by an import

[Jmapb]

On 3/17/2020 10:52 AM, Wayne Emerson, Jr. via talk wrote:

However, among your examples you cite "gnis:feature_id=*" The wiki
page for this key notes:
"Unlike other imported tags such as gnis:created=* and
gnis:import_uuid=*, gnis:feature_id=* is meaningful beyond the import.
In fact, some mappers actively add gnis:feature_id=* to features to
cite a verifiable source for the POI's existence or its name."


Agree with clemency for gnis:feature_id -- it's handy to be able to
crossreference features with the GNIS database, which you can search by
feature id here: https://geonames.usgs.gov/apex/f?p=138:1:0:

J


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

Re: [Talk-us] When is your doctor a clinic?

[Jmapb]

On 1/23/2020 8:14 PM, Shawn K. Quinn wrote:


On 1/23/20 17:29, Jmapb wrote:

However, truth be told, since the default map has ceased rendering
healthcare=*, I've found myself tagging anything smaller than a hospital
but larger than a doctor's office as amenity=clinic. For example, the
"freestanding emergency departments" that were discussed on the Tagging
list last April. This is one area where I'm not too shy about tagging
for the renderer.

Our tagging scheme needs to catch up to this and offer another option
between clinic and hospital. I must have missed the discussion about
this, or I'm not on that list; why is healthcare=* no longer being rendered?


There was an issue rendering polygons that had healthcare tags but
didn't have amenity tags, which was a lot of them, especially given the
variety of healthcare tags that don't have an amenity equivalent. If you
want to get into the nitty-gritty:

https://github.com/gravitystorm/openstreetmap-carto/pull/3731
https://github.com/gravitystorm/openstreetmap-carto/pull/3644

Even with established healthcare=* tags, though, the question of
"another option between clinic and hospital" isn't exactly settled. For
instance, some mappers seem to think healthcare=centre fits in that
slot, but others use it for a large healthcare campus that contains
several hospitals.

J


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

Re: [Talk-us] When is your doctor a clinic?

[Jmapb]

On 1/23/2020 5:30 PM, Bill Ricker wrote:

My US doctor's office *is* a clinic, but that's because they were
previously an all in one HMO before merger/spinoff. On-site blood lab,
x-ray, specialities, pediatrics, coffee shop, PT/OT, optometry,
pharmacy, ... . Multiple docs and nurses in each practice for cover.
Larger clinics in chain have urgent care, can even apply a cast if you
break a limb early enough in the day (one shift only).  Can even do
light surgery e.g. drain an abscess.

It has a corporate name, not "Dr P Smith, MD PC".
Otoh the back country family-practice partnership that took care of my
family 50 years ago had a small surgery in the British sense en-suite,
in addition to consulting and examining rooms, and could be called a
clinic - they had an autoclave and a centrifuge.


As I tag them,

amenity=doctors:
* are usually operated by (and even named for) a particular doctor (or a
small partnership)
* are usually either a general practice or specialize in a small number
of areas
* often require an appointment
* usually have typical daytime business hours

amenity=clinic:
* are usually named like a business
* feature a larger medical staff, often rotating
* offer treatment for a wide variety of issues
* generally accept walk-in patients
* often have extended hours, including 24/7

However, truth be told, since the default map has ceased rendering
healthcare=*, I've found myself tagging anything smaller than a hospital
but larger than a doctor's office as amenity=clinic. For example, the
"freestanding emergency departments" that were discussed on the Tagging
list last April. This is one area where I'm not too shy about tagging
for the renderer.

Jason

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

Re: [Talk-us] Opinions on micro parks

[Jmapb]

On 10/1/2019 10:26 AM, Frederik Ramm wrote:


Case 1: http://www.remote.org/frederik/tmp/case1.png
Two small coastal areas that look a bit like rock outcroppings.
Case 2: http://www.remote.org/frederik/tmp/case2.png
The tree-covered green area in the middle of the image


I certainly wouldn't tag either of these as a leisure=park based on the
aerial images, but I assume the mappers in question have some additional
information. In particular, though, I'd look for designated public
access (not just permissive) and some kind of actual leisure
opportunities (not just "you can legally sit on the ground here"). I
don't see evidence of those.



Case 3: http://www.remote.org/frederik/tmp/case3.png
The highlighted area in the middle of the picture straddles a street and
parts of an amenity=parking north and south of the street and seems to
rather arbitrarily cut through the woodland at its northern edge.


I think this looks parky enough, as long as it's not signed in a way to
prevent public use. Definitely has physical access, even parking, and it
looks like you could sit on a picnic blanket or fly a kite, as long as
it didn't get tangled in those power lines. But I'd be suspicious of
both the northern and southern boundaries.



Case 4: http://www.remote.org/frederik/tmp/case4.png
Red highlight is a "leisure=park" "zone=PR" (the latter probably left
over from an import). Larger, green area that is mostly overlapping this
"park" but also cutting an edge in the NW is natural=wood.


Nah, that's not a park. If someone wants to tag the operator or
ownership or protection status, sure, tag away. If it's a future park,
use a lifecycle prefix like proposed:leisure=park.

...Just my gut reactions, J



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

[Talk-us] data freshness boogie man (was: request for review of plan for scripted edit)

[Jmapb]

On 8/8/2019 5:52 PM, Bryce Jasmer wrote:


I’m really opposed to this idea of scaring people away from editing
objects with the “data freshness” boogie man argument. If someone
really cares about freshness, the entire history of an object is
available to you.


That's true for any single object. But what if you want to query for
stale data in a given area, in preparation for a survey? Accessing each
object's history makes the process exponentially more complicated. If
you can mange to do that, then you could try to skip edits by known bot
accounts... but there are always more. You can try to filter out
changesets with bot=yes, which well-behaved bots will set. But lots of
people make these wide-ranging edits semi-manually using JOSM or Level0.

I understand that this particular objection to armchair data cleanup is
far from universal. But the compulsive reformatting of incorrect data
makes me roll my eyes a bit. I find it useless bordering on ridiculous
when I see a mapped restaurant that's been gone for years, but someone's
added branding tags, someone's prefixed the website with http://,
someone's reformatted the phone number, someone's fixed the opening
hours, someone's corrected the cuisine... but nobody has bothered to see
if the place actually still exists.

I think my prejudice stems from reading this cautionary tale on the wiki
in my OSM infancy:
https://wiki.openstreetmap.org/wiki/What%27s_the_problem_with_mechanical_edits%3F
(I see now that this was originally written by Frederik Ramm, though I
had no idea who that was at the time.)

The bottom line, though, is that a well-planned, well-discussed, and
well-behaved bot is by far the *best* way to make these sorts of edits,
if someone feels they must be made. My preference would be to only touch
recently edited objects but that's by no means a dealbreaker.

Jason


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

Re: [Talk-us] Request for review of plan for scripted edit

[Jmapb]

On 8/8/2019 1:28 PM, Alex Hennings wrote:

Community,

I'm planning a scripted change and would like feedback. Plans are
outlined here:
https://wiki.openstreetmap.org/wiki/Automated_edits/blackboxlogic

I'd appreciate feedback or questions in the 'Discussion' portion of
that wiki page, or within this email list.


Hi Alex!

First, a possible typo: I think "Nodes, Ways and References" should be
"Nodes, Ways and Relations"?

I'm a fan of the +1-xxx-xxx- format, since it's the only standard
format that's visually intuitive to North American users. I often switch
numbers to this format when I make updates to an existing POI.

Personally, though, I've always felt a little uneasy about automated
updates like this because they give a false impression of the freshness
of the data. If it's been five years since any "real" updates to a POI,
I'd rather that the date of last update reflected that. It's hard to
gauge the community consensus on this issue, but IMO running this on
POIs that have been manually updated (ie not by a mass edit) in the last
6 months would be fine.

Regarding the single area code question... now that cell phones, VOIP,
and nationwide calling plans are ubiquitous, the idea that a certain
area code refers to a certain area is steadily eroding. I have started
to see a few businesses with out-of-state phone numbers on their
signs... but at this point it's still more likely that an out-of-state
area code is an error or SEO spam. I'd suggest that these would go into
your "Manually review or flag" category.

Regardless, the idea that an area can have a single "traditional" area
code is still true. Personally I have no problem with prepending the
traditional area code onto 7-digit phone numbers. (I do it all the time
in manual mapping.)

Finally, thanks for posting your tools... I see these are written in
CSharp, which I'm only tangentially familiar with. What sort of
environment would one need to build these?

Thanks, Jason



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

Re: [OSM-talk] Microsoft Buildings vs. OpenStreetMap visualization

[Jmapb]

On 8/2/2019 7:24 AM, Darafei "Komяpa" Praliaskouski wrote:

Here's a demo by azavea showing how 125 Million AI-mapped buildings
relate to 33 Million buildings currently in OpenStreetMap in the same
region.

https://demos.azavea.com/building-footprint-comparison/#4.4/38.67/-93.93


Thanks, this is interesting.

Browsing the areas I'm most familiar with in NYC (where we had a
building footprint import from city data in 2013), I find that the
buildings that are detected by Microsoft but missing from OSM are mostly
either already demolished buildings (currently mapped as
landuse=construction), small outbuildings, or simply nonexistent. In the
cemetery, Microsoft has picked out a few of the more impressive tombs
and mausoleums. And in one case Azavea seems to have failed to notice a
building that's been mapped in OSM for years (since the import.)

Browsing more rural areas in upstate NY, I see thousands of unmapped
buildings, mostly houses, that Microsoft successfully detected -- in
some cases despite tree cover. The sizes are pretty good and the
footprints are okayish. Oddly some of them seem slightly rotated, maybe
a trick of the shadows.

J


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

Re: [OSM-talk] Reordering and rewriting Good Practice wiki page

[Jmapb]

On 7/4/2019 12:40 AM, Warin wrote:

On the order of things.

Best to tell them what to do first. This provides some motivation.

Leave 'what not to do' for last, these tend to turn people away.

So I would do:

1    One feature, one OSM element

2    Good changeset comments (+Keep the history)

3    Editing Standards: (Align aerial imagery before tracing, Do not
trace from outdated imagery... Keep straight ways straight ... Mark
estimations with FIXME ... etc.)

4    Do correct errors

5    Verifiability (+Map what's on the ground, Don't map: historic
events, temporary features, local legislation etc)

6    Document your custom-tags (Don't remove tags that you don't
understand...

7    Don't map for the renderer (+ Don't misuse name tag)


I'd personally advocate for one more "don't" -- But it can be phrased as
a "do" if that helps the psychology:

"Try to keep changesets to a manageable size, both in number of changes
and geographical scope."

I believe this is commonly understood best practice, but it's only
vaguely documented.

Jason


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

Re: [OSM-talk] Proposed mechanical edit - remove blatant duplicates (sustenance=fast_food on amenity=fast_food, atm=yes on amenity=atm etc.)

[Jmapb]

On 6/14/2019 9:50 AM, Dave F via talk wrote:

On 14/06/2019 14:10, Jmapb wrote:

 If there's a problem with a well-thought-out mechanical edit, it's
highly likely to be localized,


For mechanical/bot/automated edits, errors are more likely to be
duplicated across all amendments.

If 'local mapping communities' have 'different ideas' it should be
queried as to what they are & why they're required.


Sure, when possible, but this is a belt-and-suspenders situation. The
automated edits code of conduct (
https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct#Execute_with_caution
) is pretty clear about this:

- Execute only a small number of edits wait for feedback before
proceeding with larger edits.
- One changeset covering the whole planet is hard to read. Changes
grouped into small regions are easiest to digest for human mappers.

(paraphrased)

Jason


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

Re: [OSM-talk] Proposed mechanical edit - remove blatant duplicates (sustenance=fast_food on amenity=fast_food, atm=yes on amenity=atm etc.)

[Jmapb]

On 6/14/2019 5:02 AM, Dave F via talk wrote:


That the main website is antiquated & unable to display details of
edits is not a reason to improve the database efficiently. Performing
edits in one go makes them easier to keep track of & revert, if
there's a problem.

DaveF


IMO, smaller and more gradual mechanical edits are much easier to keep
track of & revert. If there's a problem with a well-thought-out
mechanical edit, it's highly likely to be localized, either a data edge
case or a local mapping community that has different ideas. Smaller
edits allow us take a look at the actual consequences and possibly
suggest changes. And smaller reverts are also easier for the software to
handle.

Jason


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

Re: [Talk-us] Temporary closures and OSMAnd offline map downloads

[Jmapb]

On 5/30/2019 4:22 PM, Abhijit Kshirsagar wrote:

Hello all,
I'm an old OSM user and have recently moved to the US.
What is the correct procedure to submit temporary (at least a few
weeks long) road closures on OSM?
Also, how long to changes typically take to make it to the
downloadable maps that the cellphone apps (such as OSMAnd) use?

Thanks in advance,
Abhijit K
Minneapolis, MN


Howdy Abhijit, and welcome to the US, and to Talk-US!

There was a related discussion on the tagging list earlier this month:

https://lists.openstreetmap.org/pipermail/tagging/2019-May/045122.html

The considerations here have a lot to do with the duration of the
closure -- and this is closely related to the second question you asked,
about frequency of updates for the programs that use OSM data. This
frequency is entirely up to individual apps. For OSMAnd, I think it also
depends on what version you're using.

But it's highly likely that a snapshot of the map made today will still
be in use on some app or device months or even years from now. This is
one reason most people avoid tagging roads closed if the closure is
temporary.

In the thread linked above, I proposed using the "conditional syntax" to
make a temporary road closure if the dates are known. It's mentioned in
the wiki, but not much seen in the wild. There's no way to add
approximate dates though. And it's unclear if any software will actually
parse these tags correctly.

Other than that, it's really a judgement call as far as when to close a
road. If you do and the road re-opens quickly, you risk some apps
thinking it's closed for a long time to come. If the road will be closed
for months, though, I'd say it's probably better to go ahead and close
it. (Be sure to add a fixme to help remind people to open it again.)

The truth is IMO we don't have a perfect way of dealing with this right
now!

Jason


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

Re: [Talk-transit] Public transport validator+generator from Maps.Me

[Jmapb]

On 5/29/2019 11:35 AM, Alexey Zakharenkov via Talk-transit wrote:

Hello everybody!

I'm a part of team who worries about public transport status in OSM database, 
especially rapid transit transport. I want to represent a public transport 
validator+generator that somebody might find a useful facility. It's open 
source:

https://github.com/mapsme/subways

Given a list of transport networks it generates output suitable not only for 
rendering PT routes but also for routing. Meanwhile it finds errors like gaps 
in rail/road sequence in a route, absent/doubling station at a stop, etc. We 
run the validator daily and publish the results at

http://osm-subway.maps.me

The page shows that even large and important subway systems (like New York 
Subway) in OSM DB are currently corrupted and therefore unusable for practical 
purposes. Difficulties occur not only due to negligent mapping but also due to 
misalignment how to map PT. I call you, who is interested in PT, to use this 
instrument, evaluate it and give feedback. We're ready to improve this tool for 
the community sake and take into account worthwhile suggestions.

Thank you for your attention.
I'm ready to answer any questions.

Best regards,
Alexey


Hi Alexey -- I've seen this same validator on Ilya Zverev's personal
page ( http://osmz.ru/subways/ ). This one hosted at
http://osm-subway.maps.me looks like it's a slightly updated version --
should  http://osmz.ru/subways/ be considered obsolete?

The New York City subways (also busses, ferries) really are in a sorry
state. Personally I've been waiting for some consensus to develop on
transit tagging schemes before I plunge into this mess. Of course I
could be waiting forever. So at the risk of derailing this thread (ha
ha), what are Maps.me's recommendations for subway tagging?

Thanks, Jason


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

Re: [OSM-talk] mass iD validation arrives in NYC

[Jmapb]

On 5/28/2019 12:25 PM, Mateusz Konieczny wrote:


28 May 2019, 17:13 by jm...@gmx.com:

Any other suggestions?

Suggest user to split edits into smaller chunks.


Yes that would be far preferable, and I did message this user. That
doesn't address the immediate question of how to attempt QA on these two
changesets. And the larger problem of other users making similar
changesets, in this city and thousands of other densely mapped places on
the planet, is still looming.

I can (and do) plead with people to keep changesets small, but the
nature of the process has changed. Before, a casual making hundreds of
changes in a single changeset was pretty rare, because they'd actually
have to *make* hundreds of changes. Now they just have to agree to them
-- and as far as they can tell they're being asked to do so by OSM
itself, so it's highly likely they will.

(And sidebar -- I like the idea of the
https://wiki.openstreetmap.org/wiki/Good_practice page including some
advice about keeping changsets to a manageable size -- both number of
changes and geographic area. Something to point to when trying to make
the case for smaller changesets.)

J

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

[OSM-talk] mass iD validation arrives in NYC

[Jmapb]

See yesterday's changesets:

https://www.openstreetmap.org/changeset/70676813 (
https://nrenner.github.io/achavi/?changeset=70676813 )
https://www.openstreetmap.org/changeset/70676888 (
https://nrenner.github.io/achavi/?changeset=70676888 )

I believe this is just a casual user browsing around in iD and making
the suggested changes it advises -- to about 1000 objects. These giant
changesets are nearly impossible to review. My fear here is that iD's
new validator will make QA extremely challenging in dense areas.

Scrolling through the tag additions, these changesets look almost
identical to the behavior of a bot... or rather like 6 or 7 bots
operating at once. If they *had* been made by a bot that was following
the mechanical edit guidelines, they could be comprehended and reviewed.
But the various tagging changes are all mixed up together in a single
changeset, along with whatever the mapper reidpelton's *actual* changes
were -- if any.

So how do I even begin to do QA on this? I don't see any options other
than 1) mass-revert or 2) skip review of all large changesets that
appear to be triggered by iD validation. Any other suggestions?

Jason


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

Re: [OSM-talk] iD invents nosquare=yes for buildings which should not be squared

[Jmapb]

On 5/9/2019 6:21 PM, Michael Reichert wrote:


JOSM runs its validation rules only on objects modified or created in
the current session. This seems more sensible both for experienced users
and newbies for two reasons:

- Uses don't get overwhelmed with dozens or hundreds of reports on
   objects they did not touch.


This makes perfect sense, and in fact I see that "Almost right angle
buildings" is still in my JOSM validator option list, and still
checked.  I don't know what caused the rash of building squaring that I
saw in NYC -- perhaps the sensitivity was adjusted at some point? I
haven't had this validation error come up in my own work for a long time.


- If users follow suggestions how to fix blindly (we cannot expect an
   unexperienced iD user to have the same knowledge as the average JOSM
   user), they are used as living bots running validation rules on
   randomly selected areas of the map. One might call this a hidden
   automated edit.

In difference, iD runs its validation rules on all loaded objects.
https://github.com/openstreetmap/iD/issues/6332#issuecomment-490494331


That's a good way to describe a lot of iD's effects in general --
mappers become living bots implementing the iD devs' ideas, under the
impression that these are the official recommendations of the OSM project.

Jason


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

Re: [OSM-talk] iD invents nosquare=yes for buildings which should not be squared

[Jmapb]

On 5/9/2019 4:14 PM, Michael Reichert wrote


Quincy Morgan, one of the maintainers of iD, invented a new tag called
nosquare=yes today which should be added to buildings which are not
square and should not be flagged by iD's validator.


This strikes me as a pretty bad idea. I map in NYC where we have lots,
lots, lots of nearly-square buildings with official footprints imported
from the city's open data initiative. When a mapper not familiar with
the history here gets a message from iD (which, to many mappers, is
indistinguishable from getting a message from OSM itself) encouraging
them to square a building, they'll do it because it seems like the right
thing to do. So the official, highly-accurate footprints are lost. And
adjacent buildings with shared nodes are also distorted.

If I were to communicate with this mapper and say "Hi, welcome, please
don't square the buildings" it will simply be confusing because the
official editor, hosted at https://www.openstreetmap.org, told them they
should.

JOSM's validator used to flag nearly-square buildings here, and it
caused thousands of unnecessary and inaccurate updates to building
footprints. And of course people doing these thought they were doing the
right thing -- if the validator says there's a problem, there's a
problem, right? Fixing it is helping the map!

I'd hate to see iD go down the same road. And I certainly don't want to
mass-tag all of NYC's imported buildings with nosquare=yes.

J


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

Re: [Talk-us] Parks in the USA, leisure=park, park:type

[Jmapb]

On 4/26/2019 9:49 PM, OSM Volunteer stevea wrote:

Other than that I can't think of any tags that would be applicable to
these sorts of situations. We tend to tag the regulations themselves,
not the extent to which they're adhered to. Certainly just calling it a
park because kids play there doesn't seem consistent with OSM standards.
We don't raise the speed limit in places where everyone speeds, or tag
bicycle=yes on ways where they're prohibited but frequently used.



No, I think leisure=playground aligns a bit more closely with "kids play here," 
though some people like snap-tight definitions, others consider things as much more 
elastic.  It's difficult to please everybody; semantics can be messy.


Certainly. But speaking as a map user, if I saw a playground on a map
and then arrived there and found it was just an empty lot or an
undeveloped bit of land, I would find fault with that map. So if these
places (kids play here but it's unofficial) are to be mapped, I'd
suggest different tagging.

If recreation really is the primary human activity in these areas, you
might consider landuse=recreation_ground -- though the way I read the
wiki, it sounds like the intended use is a little more formal than the
situations you're describing.

J


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

Re: [Talk-us] Parks in the USA, leisure=park, park:type

[Jmapb]

On 4/25/2019 8:39 PM, OSM Volunteer stevea wrote:


A hazy sort-of-emerging along with this is wider recognition that a proto_park thingy exists.  Put 
it in the planning departments "bin" for "department of parks budget, depending how 
much we convert protected_area into human-leisure-activity in the next budget or ten."  Maybe 
never, humanity and this planet can hope.  Hey, this could be a park someday if and as we improve 
it.


Sounds like a good case for some lifecycle prefixes --
proposed:leisure=park or planned:leisure=park. (No one seems to know
exactly what the difference is, or if one of these is further along in
the lifecycle than the other. Regardless, proposed:*=* is much more
widely used.)

Once park construction has begun, construction:leisure=park. And finally
just leisure=park when it opens.



I've seen kids on bikes go under fences and around things and treat "certain 
areas" just like an admittedly fully raw and completely undeveloped park, even 
though it isn't one.  Sometimes with respect, simply hiking around.  What is that?  
Humans being human.  We should map those, accurately.


We have access=permissive, but I don't think a hole in a fence really
counts as "permissive." (I think de facto access to an area with no
fence/no signage/no enforcement *could* be called permissive.)

Other than that I can't think of any tags that would be applicable to
these sorts of situations. We tend to tag the regulations themselves,
not the extent to which they're adhered to. Certainly just calling it a
park because kids play there doesn't seem consistent with OSM standards.
We don't raise the speed limit in places where everyone speeds, or tag
bicycle=yes on ways where they're prohibited but frequently used.

Jason


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

Re: [Talk-us] What is sold in Value Village? (shop=second_hand vs shop=clothes)

[Jmapb]

It's like a second-hand department store. I think shop=second_hand is
correct tagging in this case, barring any surveyed details about the
inventory of the particular branch. J

On 4/26/2019 9:55 AM, Evan Derickson wrote:

They sell a mix of everything...certainly a lot of clothes, but also
furniture, kitchenware, sporting goods, etc. You can see more details
at https://www.valuevillage.com/donate/what-we-take

On Fri, Apr 26, 2019 at 5:46 AM Mateusz Konieczny
mailto:matkoni...@tutanota.com>> wrote:

Is it a second hand shop, but what it is primarily selling?

Clothes? Or something else? Or is there no dominating product
and it is selling mix of everything?

I am asking as name-suggestion-index has it as shop=second_hand
without any indication of sold product and it seems to me that
shop=clothes + second_hand=only would be preferable tagging.

name-suggestion-index is used at least by iD and Vespucci so improving
it makes mapping a bit easier.

nsi issue: https://github.com/osmlab/name-suggestion-index/issues/2587
___
Talk-us mailing list
Talk-us@openstreetmap.org 
https://lists.openstreetmap.org/listinfo/talk-us



--
Evan Derickson
derickso...@gmail.com 

___
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] trail tagging

[Jmapb]

On 4/20/2019 9:18 AM, Aaron Forsythe wrote:


> cycleway ; bike path ; paved path, open to bikes, & I've never seen
one that

> wasn't open to pedestrian too

These do exist.  There are a few around here (Missouri, USA). In these
cases, there’s usually a separate path for pedestrians so cyclists can
have a path off the roadway, but not have to dodge pedestrians.  They
are rare enough though that defaulting to allow pedestrians would
likely still be the best option.


The Manhattan Bridge in NYC is another example. The path on the
southwest side is for pedestrians only, and the path on the northeast
side is for bicycles only.

https://www.openstreetmap.org/way/357260631
https://www.openstreetmap.org/way/46179218

(That's how they're signed anyway -- compliance with those rules is
another story.)

Personally I would encourage explicit tagging of foot=yes on
highway=cycleway if foot traffic is permitted, and discourage routing
foot traffic over cycleways without this tag.

J


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

Re: [OSM-talk] HTTPS all the Things (Automated Edit)

[Jmapb]

On 2/26/2019 10:58 AM, Michael Reichert wrote:

Hi Bryce,

Do you have any safeguards against POIs which do not exist any more and
whose domains are owned by domain sellers now? They often have a very
basic website with a message like "This domain is for sale." and some
advertisement. I would not be surprised if they support HTTPS (and maybe
HTTPS only) these days. Update website=* and similar tags would not be a
benefit to OSM but simulate some kind of up-to-dateness.

Best regards
Michael


Good point -- I've seen a fair number of these, though I can't say for sure if 
any of them have been redirecting to https. If they're not yet, though, they 
will soon, now that free trusted certs are widely available.

When the URL in question is still present on the POI's signage, I've been 
changing website= to disused:website= for these (and for the 404s etc.)

Jason
 



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

Re: [OSM-talk] HTTPS all the Things (Automated Edit)

[Jmapb]

On 2/22/2019 3:48 PM, Mike N wrote:


On 2/22/2019 3:36 PM, Jmapb wrote:
IMO the value of an automated edit when there's already a redirect in 
place is minimal enough that I don't think it justifies bumping the 
version and modification date. Just my opinion.


  The value of the automated edit is that there is a small improvement 
in security.   Assuming that someone ever clicks on a link in our 
data, it is more secure to go directly to the HTTPS site rather than 
start with the HTTP site.


True, that's exactly why I update these when I find them. I don't think 
it warrants an automated edit, but there's room on the map for those who 
do ;)


J


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

Re: [OSM-talk] HTTPS all the Things (Automated Edit)

[Jmapb]

On 2/22/2019 2:02 AM, Bryce Jasmer wrote:
I have written a script that will search for OSM objects that have a 
website tag that explicitly states "http://...; or implicitly uses 
http by leaving of the protocol specification. The script will then 
loop through all that it discovers and asks the http site if it will 
redirect me to the secure version of the website over the https 
protocol. If it does, I will update the database with the new value.


This has a couple of advantages. From now through the end of time, any 
user clicking on one of those links will be spared the time it takes 
to establish the connection, ask if there is a secure version of the 
site, and tear down the connection. It's on the order of 10-200 ms to 
do, but over the life of the link and the number of objects that are 
clicked and the population, this could save centuries of time :-)


Another advantage is that it will make https more pervasive and 
hopefully people will start thinking https and forgetting all about 
http. A more secure internet is in all of our best interests.


Anyway, I'd like to (slowly) run this across the planet. I've 
discussed this on the US Slack channel and have performed the actions 
on the United States already. I've addressed many questions and have 
heard no strong objections. I'm seeking feedback from the larger 
community now before proceeding.


The wiki page is 
https://wiki.openstreetmap.org/wiki/Automated_Edits/b-jazz


The Slack conversation is available, but has died down and the 
transcript is available at the wiki page mentioned above.


The diary entry with some more conversation is at the bot's page: 
https://www.openstreetmap.org/user/b-jazz-bot/diary/47743


The source code is available on GitLab for review: 
https://gitlab.com/b-jazz/https_all_the_things


Example changeset for a run over the "9yfd" geohash: 
https://www.openstreetmap.org/changeset/67454775


I welcome your input.


Hi Bryce -- I've been observing these automated changes around NYC. I'd 
like to humbly request you run these sorts of large projects by the 
Talk-US mailing list before implementation, since there are many mappers 
(dozens of us!) who don't choose to spend time on Slack. (Apologies if 
you did post and I missed it -- that's bound to happen sometimes.)


Personally I've been updating these tags to https manually as I come 
across them (sometimes prompted by Keepright), IF I can verify that the 
business (etc) in question is still a going concern and still located in 
the same place.


IMO the value of an automated edit when there's already a redirect in 
place is minimal enough that I don't think it justifies bumping the 
version and modification date. Just my opinion.


(Also, why are you adding a trailing slash to everything?)

Thanks for posting your code -- I'm contemplating an automated import of 
my own and I've been meaning to browse some modern bot code to get me 
started.


Jason

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

Re: [OSM-talk] WhoDidIt Feeds

[Jmapb]

On 2/12/2019 6:52 PM, Steve Doerr wrote:


Feeds have now resumed.


Looks like they're slowly catching up... up to Feb 1st now. J

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

Re: [Talk-us] Fixing road network in New York — MapRoulette challenge

[Jmapb]

On 2/9/2019 9:30 AM, Ilya Zverev wrote:
Yesterday I took ~1 mln rides we made in December and matched them to 
the OSM road network. With that I found a few hundred points where an 
actual trace diverged from the matched one quite often. This usually 
means a oneway tag is wrong, or a turn restriction is incomplete.


The result is this MapRoulette challenge: 
https://maproulette.org/mr3/challenge/3570


Have fun,
Ilya

Thanks, Ilya -- this *is* fun! You've caught a lot of bad tagging that's 
been sitting for years. Looks like we're about a third of the way 
through these already. Teamwork!


If you have the resources, I'd love to see this challenge repeated every 
few months so we can continue hunting these bad tags to extinction, and 
also keep up with new changes. A couple of suggestions, and I don't know 
how realistic these are since this is my first time using Maproulette:


 - From each task, before entering the edit mode, it would be great to 
have a direct link to https://www.openstreetmap.org/directions with the 
start and end locations encoded, so we can immediately check if the task 
in question is still an issue. A fair number of them have already been 
fixed, and/or I can't replicate. As of now my workflow is: Zoom in, turn 
on data layer, click a building, click the 
https://www.openstreetmap.org/way link in the popup, pan around the map 
to find approximate start and end points, and get directions via OSRM. 
It would be great to save some steps and to get the exact same start end 
end points you used.


 - When invoking iD, the changeset comment field is auto-populated with 
#maproulette -- is it possible to also auto-populate with the challenge 
and task number?


Thanks for your work, Jason


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

Re: [OSM-talk] WhoDidIt Feeds

[Jmapb]

On 2/9/2019 7:39 AM, Steve Doerr wrote:

None of my WhoDidIt RSS feeds seem to have updated since 18/01/2019. 
The main one is 
http://simon04.dev.openstreetmap.org/whodidit/scripts/rss.php?bbox=0.184967,51.325448,0.618584,51.453992


Has this service been discontinued or is there a known problem?

I also have a feed that's still live but has no new posts since Jan 
17th. Saw some complaints in one of the German forums but no one has any 
insight. I would consider the WhoDidIt service temporarily (hopefully 
temporarily) out of commission.


As a serviceable substitute, OSMCha can generate an RSS feed for any 
saved filter set. It can be set up to report all changes in a given 
area, though it seems to generate a lot more false positives than 
WhoDidIt. (And it doesn't give all the handy clickable links right in 
the message like WhoDidIt does.)


J


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

Re: [OSM-talk] Ground truth for non-physical objects

[Jmapb]

On 12/11/2018 9:41 AM, Rory McCann wrote:

On 11/12/2018 12:38, Tomas Straupis wrote:

   If someone puts a label "Military academy" on their house, would we
map it as an actual military academy?


No, but you would put "addr:housename=Military academy".


Sidebar, according to my reading of the address tagging standards, one 
should only tag addr:housename=* when it's an official (or at least de 
facto) part of the postal address. It's not for people who just decide 
their house has a name and write that name on a sign -- though you can 
use name=* for that. J



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

Re: [Talk-us] Anyone feel like helping another mapper in New York?

[Jmapb]

On 12/9/2018 6:38 AM, Andy Townsend wrote:

On 23/11/2018 21:24, Andy Townsend wrote (heavily snipped):

Hello,

Over the last couple of months there have been edits by a new mapper 
in New York who seems to like changing things but hasn't quite got 
the hang of what they're doing yet.  ...   Comments can be seen at 
http://resultmaps.neis-one.org/osm-discussion-comments?uid=8356718 .


They've edited again and I've had to revert again due to "random" node 
drags.  It'd be great if someone a bit nearer than me could help - or 
at least "weed" their edits afterwards with a bit of local knowledge.


I sent him a message offering to help, but if he doesn't respond to you, 
I doubt he'll answer me either.


I'm not really close enough to have local knowledge of the area... It 
looks like the most active user in the area is Unggo99, so maybe try to 
getin touch with him/her.


Thanks for your diligence -- vive la carte! - Jason


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

Re: [Talk-us] USPS Post Boxes

[Jmapb]

On 9/25/2018 10:37 AM, Martijn van Exel wrote:

But there's also an opportunity to have the community have another 
look at the area surrounding the nodes. It's only ~4600 items: 
http://overpass-turbo.eu/s/Cg0 .


By far the majority of post_boxes in the USA have no operator tag: 6871 
by my count. These are highly likely to be the USPS blue boxes but of 
course it's better not to assume that. They'd be a good candidate for a 
community review.


For those tagged with an operator, most are one of the many variations 
on the US Postal Service name:

3609 * usps
199 *us postal service
125 * u.s. postal service
12 * us post
11 * united states postal service (used to be popular before Leif's mass 
edit)

4 * us mail (some older post boxes still say this on the side)
1 * united states postal office
1 * usps express mail
1 * usps.com

No doubt I've missed a few variations. There are also many (hard to 
count) where the name of the local post office branch is used for the 
operator.


Then we have the familiar shipping companies:
202 * ups
47 * united parcel service
4 * ups store
1  * the ups store
206 * fedex
9 * federal express
1 * fedex office
3 * dhl

Most of the rest are typos or questionable data. One instance of "multi" 
and one of "UPS; DHL; FedEx"... I've never seen a postal box with 
multiple operators in real life; my guess would be it's a few boxes next 
to each other.


J

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

Re: [Talk-us] USPS Post Boxes

[Jmapb]

On 9/6/2018 6:44 PM, Leif Rasmussen wrote:

First, for keeping the tagging style as consistent as possible, each 
post box will be given the tag "operator:wikidata"="Q668687".  This 
way, even if the operator=* tags are changed later on, all post boxes 
will still be consistent and easy to querry.


Earlier I wrote in favor of keeping operator=USPS. Just to add, I don't 
see any problem with adding this operator:wikidata tag, but there's no 
reason to expect anyone else will be adding it to newly mapped mailboxes 
going forward, right? I mean, "United States Postal Service" may be a 
chore to type, but nothing compared to typing "operator:wikidata=Q668687".


J

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

Re: [Talk-us] USPS Post Boxes

[Jmapb]

On 8/28/2018 3:31 PM, Leif Rasmussen wrote:

Hi everyone,
A couple of days ago, I noticed that different post boxes in the 
United States had different ways of tagging that they were part of the 
USPS system.  Roughly 60% had "operator"="USPS", 40% 
"operator"="United States Postal Service", and about 15 similar to 
"operator"="United States Post Services" or "United States Post 
Office".  I wanted to make them all the same, so I asked on the OSMUS 
Slack group about the tags, and most people supported "USPS".  I then 
proceeded to upload a changeset manually converting 1500 "United 
States Postal Service" or similar to "USPS".  I should have waited 
longer before uploading.

https://www.openstreetmap.org/changeset/62020302
https://overpass-turbo.eu/s/Boq
All post boxes in the USPS system now have "operator"="USPS".
After uploading, people expressed concern about the choice of "USPS" 
over "United States Postal Service".  The wiki states that 
abbreviations should be expanded, "USPS" could be confused with other 
agencies 
, and 
this counted as an automated edit, which should have had better 
planning with the OSM community.
I would now like to propose converting all post boxes with the tag 
"operator"="USPS" to "operator"="United States Postal Service".  I 
would also like to add the tag "operator:wikidata"="Q668687" to the 
post boxes that currently have "operator"="USPS".  Please reply with 
any feedback or concerns you have with this proposal.


Thanks for looping us in, Leif. Haven't made it to the slack group yet, 
but when I noticed that change I thought to myself "thank the Lord, it's 
over!" Every time I've tagged a post box I've managed to convince myself 
that I did it wrong the previous time. So I rotated between "USPS", 
"usps" and "United States Postal Service" and figured I'd get around to 
fixing them when my brain settled down. Seeing someone else take the 
initiative was a relief, despite the understandable grumbling about 
automated edits.


Now that it's done, I'm in favor of making an exception to the 
no-abbreviations rule for a fixed set of couriers, so sticking with 
USPS. It's easy to tag and read, and I don't think it's truly 
ambiguous... if the United States Power Squadrons start a courier 
service, *they* should be tagged with the fully expanded name.


Another reason is that there are plenty of private company post boxes, 
and I'd like the tagging style to be consistent as possible, with the 
commonly-used compact versions of their names. I feel operator=UPS, 
operator=FedEx, operator=DHL will be easier to write, maintain, and read 
than operator=United Parcel Service, operator=Federal Express, 
operator=.. well, I still can't figure out what DHL actually stands for.


Also -- not an issue for postboxes per se, but I've found occasion to 
tag some some shops with the shipping companies they offer, and the idea 
of a semicolon-seperated list of fully expanded shipping company names 
makes me weary.


(No problem with adding the operator:wikidata tag.)

Thanks, Jason



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

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

[Jmapb]

On 8/10/2018 1:33 PM, Barry Hunter wrote:



But in the case of a long driveway wouldnt the address be attached to 
the entryway (so that directions etc, can route to the right location)?


This isn't very common, and there's no documentation of this practice on 
the addr or service=driveway wiki pages. (There is mention of adding 
addr:* tags to an "entrance/gate", but no suggestion as to when this 
should be done.)


From what I've seen, usually the house at the end of the driveway would 
get the addr:* tags, and the routing engine would route down the 
driveway -- or, if the driveway is tagged access=private, to the nearest 
spot on the public road, which is *usually* pretty close to where the 
driveway starts.


In your scenario, what gets the addr: tags? The driveway itself, or the 
intersection node?


J





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

Re: [Talk-us] Senseless racism

[Jmapb]

On 7/25/2018 12:57 PM, Christoph Hormann wrote:


I am somewhat amazed by the fact that hardly anyone from the US
community (where a lot of mappers routinely map abroad and should be
able to empathize with Frederik being concerned about an area where he
has no first hand knowledge of) seems to find it necessary to speak up
against this.
Okay, count me in, American, Texan even: Cut out this racist/nationalist 
bull. Respond to people's comments without name-calling. Put the quality 
of the map first and don't take criticism personally. Grow up, apologize 
privately if you're able to, and move on.


If you feel the need to show up some other nationality, do it by making 
a map so excellent that they weep.


Jason

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

Re: [Talk-us] US building footprint data

[Jmapb]

Thanks Jubal, this looks like fantastic no-nonsense work. Seems like it 
might be wise to wait until after the Milan conference to see if a 
recommended workflow will emerge to begin putting these footprints to use.


Any plans to publish data for other countries? How about quarterly diffs?

jmb


On 6/28/2018 12:37 PM, Jubal Harpster wrote:


Hi Everyone,

Today Microsoft released ~125M computer generated building footprints. 
You can read about the release on the Bing Maps Blog 
(https://blogs.bing.com/maps/2018-06/microsoft-releases-125-million-building-footprints-in-the-us-as-open-data)


There is additional technical detail on the creation process and links 
to directly download the data in geojson format in the public git repo 
here (https://github.com/Microsoft/USBuildingFootprints)


Enjoy.

-Jubal



___
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

[OSM-talk] Sidewalk symmetry

[Jmapb]

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


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


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


Thanks for you thoughts, jmb


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