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