Re: [Talk-us] Potential Mechanical Edit to remove access=private from Amazon Logistics driveways in NH

[Greg Troxel]

A further issue we haven't talk about:

  How much detail is ok on residential property, from a privacy
  viewpoint?  Is mapping of "no trespassing signs" going too far?

We show structures, and we show driveways.  These don't feel invasive
given imagery.  They are very useful for navigation, particularly with
long driveways.   We don't map much else.

To me, marking individual driveways about whether they have a no
trespassing sign or not, is a bit much.  It feels a bit dangerous, in
terms of getting it wrong and expectations.  Yes, you can see them from
the road, but still.

I also don't think it's all that useful.  When you are going somewhere,
you need to pay attention, regardless of the map.  And you know why you
are going, and if you have some kind of permission, and we are not going
to automate that.

So to me, private_signed and private_unsigned, or whatever, are
extremely close to the same thing.  I see signed or not as a minor
detail, and I would prefer not to map it.  (But, I won't tell you not to
map it.)

I do object to a tagging scheme unless it has a tag appropriate for
unsigned residential driveways that is viewed as not-really-wrong for
driveways that happen to be signed.  I mean that in the sense that it
isn't objectionable, not that it can't be refined.  Sort of like
"building=yes" is not wrong but changing it to "building=barn" is
better.


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

Re: [Talk-us] Potential Mechanical Edit to remove access=private from Amazon Logistics driveways in NH

[Greg Troxel]

Matthew Woehlke  writes:

> On 31/08/2020 11.19, Greg Troxel wrote:
>> What I objected to was not "that is your opinion; many others disagree"
>> but "that is your opinion but *no one else* sees it that way".  If you
>> didn't really mean that, sorry for overreacting.
>
> Fair enough. I probably should have said something like "my
> understanding is that this is contrary to the community
> consensus". It's always possible that what appears *to me* to be the
> community consensus looks different to others.

Interpreting consensus is indeed very hard.

I think OSM has a general problem in this area, where

  there is discussion about something

  that leads to rough consensus for the range of situations in the
  discussion

  words are written down to describe this

  new situations arise

  people interpret the text to apply to the new situations, as if the
  text has some enormous standing, even though it describes consensus in
  different situations


So for example,  I'd agree that "access=private" generally means "only
with permission", but I don't think the original discussions that led to
it contemplated the folloeing notions:

  lack of no trespassing sign doesn't mean you 100% can't, so private
  isn't ok unless there is a sign.

  "only with permission" does not match "residential driveways are
  almost 'only with permission' with narrow social exceptions, so they
  are almost the same thing, far more than they are different" so
  private for an unsigned driveway is wrong.

I don't think either of those points would have been agreed on had they
come up in the discussion.  Thus I think we as a group overly
extrapolate from what we think was consensus.




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

Re: [Talk-us] Potential Mechanical Edit to remove access=private from Amazon Logistics driveways in NH

[Greg Troxel]

Matthew Woehlke  writes:

> On 31/08/2020 10.54, Greg Troxel wrote:
>> Matthew Woehlke writes:
>>> *You* may see it this way. The rest of the community does not.
>>
>> A declaration that every other member of the community disagrees is
>> unreasonable.
>
> I'm not sure if this is directed at me or at Mike. If at me, I'll
> point out that the fact we're having this conversation in the first
> place is because someone strongly disagrees with residential driveways
> being access=private "by default". Nor is it the first time I've
> encountered that opinion.
>
> Honestly, my initial opinion on the matter was closer to Mike's, but
> others told me I was wrong.

That's far more reasonable.  I think it's obvious that there is
disagreement, and it's also obvious that this is very difficult.

What I objected to was not "that is your opinion; many others disagree"
but "that is your opinion but *no one else* sees it that way".  If you
didn't really mean that, sorry for overreacting.

>>B) private shopping centers where the public is welcome, to shop.
>>(access=customers, mostly)
>>
>>C) private land where use is known acceptable (access=permissive)
>
> Even this is not clear. *My* understanding is that most businesses are
> closer to access=permissive, with access=customers referring more to
> places that are explicitly signed as "customers only". In most
> shopping centers, for example, it seems acceptable to go there just to
> walk around even with no intention of purchasing anything. (At least,
> I know that people do so...)

I agree this is tricky.I think the issue for unsigned shopping
centers and parking lots is:

  it is basically always ok to go there to shop (looking at things with
  the intention of maybe buying them)

  it is usually/sometimes ok to visit without intent to buy ("mall
  walking").  One can kind of view this as almost-customers as the mall
  more or less permits/encourages this in the hopes that people will buy
  things because they are there anyway.

  It is sometimes ok to just park there to go someplace else nearby, or
  leave a car for carpooling.  And sometimes not.

To me, permissive means "the landowner is known not to object to the
extent that this can be treated as access=yes, except that ther is no
explicit grant of permission and defintely no legally-enshrined right."
That's a far broader notion that a parking lot at a business without a
customers-only sign.  In that case, I think it's very much in the grey
area between prohibited and acceptable,   Permissive is a declartion
that it is accceptable.

So I would lean to marking lots and way at businesses as
access=customers normally, and wanting a tag to say that there is an
actual sign limiting this.


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

Re: [Talk-us] Potential Mechanical Edit to remove access=private from Amazon Logistics driveways in NH

[Greg Troxel]

Mike Thompson  writes:

> On Mon, Aug 31, 2020 at 7:46 AM Matthew Woehlke 
> wrote:
>
>> On 30/08/2020 10.00, Greg Troxel wrote:
>>
>> > What is the actual problem with other people's driveways being marked
>> > access=private on the map?  yes, driving on is usually technically not
>> > illegal, but unless you are going there because you were invited for
>> > have a reason they'd approve of, it's basically not ok.
>>
>> The objection is that access=private currently *has* an understood
>> meaning, and that meaning is *no* access without permission, not what
>> you described above.
>
> Sounds like my driveway.  If you are using my driveway without my
> permission, either implicit (e.g. delivering a package) or explicit, I am
> going to ask you to leave.  I think you are conflating whether something is
> "not allowed" with "can be prosecuted as a crime."

Indeed.  When I look back at use without some kind of
permission/invitation, it's been (my categories):

OK and OKish:

  someone collecting petition/ballot signatures (semi-ok, depending, but
  clearly socially acceptable)

  neighbor bringing food as welcome-to-neighborhood visit

  neighbor bringing misdelivered package

  adjacent landowner coming to discuss something reasonable

  neighbor coming to say hello and talk about what happened in hurricane
  of 1938 since he ran home across the then-undeveloped land as the
  storm started.

  people trying to visit the next-door neighbor and going up the wrong
  driveway

not OK:

  proselytizers (not unlawful, sort of semi-ok socially -- really the
  edge of normal)

  people trying to sell things

and importantly doesn't include things like:

  people who are walking for exercise and decide to walk up to houses
  and back just for fun

  people teaching their kids to drive


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

Re: [Talk-us] Potential Mechanical Edit to remove access=private from Amazon Logistics driveways in NH

[Greg Troxel]

Matthew Woehlke  writes:

>> I agree we need a new tag.  As I see it
>>
>>access=yes
>>
>>  legally-enshrined right of access, like a public street.  (Also used
>>  for private conservation land where the landowner invites the
>>  public, even though technically they could change the rules.)
>>  Perhaps shopping centers, even though not a right, it's close in
>>  practice.  Essentially always in truly public places.
>>
>>access=permissive
>>
>>  no *right* of access, but generally understood that the landowner
>>  does not object to typical use.  Often on trails not near houses
>>  that cross private land, but without an easement.  Basically can
>>  only be added by a local because it is essentially never signed.
>>
>>access=private
>>
>>  There is no right of access for random people.  There is no social
>>  expectation that it is reasonable for people to go there for for
>>  arbitrary purposes.  (For example, an actual neighbor coming to
>>  introduce themself, etc. is ok.)  This is the default assumption for
>>  driveways in New England - basically actual neighbors behaving in an
>>  actual neighborly way that they wouldn't mind someone else doing at
>>  their house is ok, deliveries ok, maybe gathering signatures for
>>  ballot access ok, and pretty much anything else not ok.
>
> *You* may see it this way. The rest of the community does not.

A declaration that every other member of the community disagrees is
unreasonable.  This is a complicated situation that does not neatly fit
the existing notions.

However, I meant to describe the categories, more than the binding of
tags to categories.  I think it's clear we need finer-grained tagging.

access was originally and mostly is about "The public has an official,
legally-enshrined right of access; i.e., it's a right of way." and many
of the flavors are about who/when has that right.  It is very clear that
for residential driveways there is no general right of access.

Where access is unclear is the space between:

  someone has a legally-enshrined right of access to use the way
  someone using the way is breaking the law

There are four big categories in between

  A) government or privete conservation land or parks, where there is no
  right of access, but socially it is almost like there is.
  Specifically, the government can't tell you you can't use the road
  (absent emergency orders, out of scope), but the Conservation
  Commission can announce that an area is closed to human use for X
  months to protect some bird, or whatever.  Still, access is ok almost
  always - there is just no right.  We typically mistag this as yes, or
  leave it empty.

  B) private shopping centers where the public is welcome, to shop.
  (access=customers, mostly) 

  C) private land where use is known acceptable (access=permissive)

  D) private land where what use is acceptable is highly limited (the
  situation under discussion, no good tag)

Part of the point is that for a residential driveway with no signs, the
actual semantics of access is far closer to access=private than any
other currently-defined access value (from
  https://wiki.openstreetmap.org/wiki/Key:access
).   It's really "acesss=private, plus if you are a neighbor being
neighorly, or a few other things it's ok".

The wiki does not seem to give an access default for highway=service.
They are not generally not legal roads and thus access=yes is completely
not ok as a default.  Arguably "customers" is a good guess for
retail/commercial and the new tag we are arguing about, for residential.


In using somebody else's driveway, the only things/circumstances that I
would do different for a driveway with or without a no trespassign sign
are:

  knock on door, ask to sign nomination papers for election,
  etc. (anywhere)

  check on wellbeing after a storm (neighbors)

  look for misdelivered packges (neighbors)
  
  introduce myself, invite people to neighborhood party, etc. (neighbors)

  bring kids on halloween, only if the light by the door is on (somewhat
  broader than neighors, and the light being on *on halloween* is more
  or less an invitation)

This is really very limited, and why I see private as being a very close
fit, far closer than any other tag we have.  In other words, the total
semantic error from using it is the lowest possible error compared to
all other choices.

>> What is the actual problem with other people's driveways being marked
>> access=private on the map?  yes, driving on is usually technically not
>> illegal, but unless you are going there because you were invited for
>> have a reason they'd approve of, it's basically not ok.
>
> The objection is that access=private currently *has* an understood
> meaning, and that meaning is *no* access without permission, not what
> you described above. I don't think it's reasonable to change that
> definition, as it would invalidate huge amounts of the map.

Do 

Re: [Talk-us] Potential Mechanical Edit to remove access=private from Amazon Logistics driveways in NH

[Greg Troxel]

On 8/30/20 11:00, Mike Thompson wrote:



On Sun, Aug 30, 2020 at 8:04 AM Greg Troxel <mailto:g...@lexort.com>> wrote:




   Being on someone's land without permission is trespassing, but
this is
   not a crime.

not a crime, until the land owner asks you leave and you fail to do so, 
at least in Colorado.


Exactly same as here and I believe NH.

  "Trespassing" is not a crime.

  "Trespass after notice" is a crime.

I was merely making the distinction between "public right of access" and 
"trespassing (without notice)", as being very different.


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

Re: [Talk-us] Potential Mechanical Edit to remove access=private from Amazon Logistics driveways in NH

[Greg Troxel]

"Alex Weech"  writes:

> Another thing I just thought of over breakfast, in New Hampshire by
> default private land has public access, and landowners have to post
> that trespassing is not allowed. It could be that that's a quirk of
> this part of the world, and other places don't have a posting
> requirement, which is why there's some cultural disconnect.

It is likely the same law has Mass, but I think you have the details of
"public access" subtly wrong.  I think the law says:

  Being on someone's land without permission is trespassing, but this is
  not a crime.

  If it is posted, or you have been told, then it is a crime.

From that, one can not conclude that "by default private land has public
access" in the OSM sense.  You can only conclude that "if you walk on it
you are not committing a crime".  In OSM, access=yes means "the public
has a legally-enshrined right of access", so not only can you go there,
but other people cannot tell you not to go there.  This notion of a
right is foundational to access=yes.

I agree we need a new tag.  As I see it

  access=yes

legally-enshrined right of access, like a public street.  (Also used
for private conservation land where the landowner invites the
public, even though technically they could change the rules.)
Perhaps shopping centers, even though not a right, it's close in
practice.  Essentially always in truly public places.

  access=permissive

no *right* of access, but generally understood that the landowner
does not object to typical use.  Often on trails not near houses
that cross private land, but without an easement.  Basically can
only be added by a local because it is essentially never signed.

  access=private

There is no right of access for random people.  There is no social
expectation that it is reasonable for people to go there for for
arbitrary purposes.  (For example, an actual neighbor coming to
introduce themself, etc. is ok.)  This is the default assumption for
driveways in New England - basically actual neighbors behaving in an
actual neighborly way that they wouldn't mind someone else doing at
their house is ok, deliveries ok, maybe gathering signatures for
ballot access ok, and pretty much anything else not ok.

  access=private
  sign:no_trespassing=yes

Further means there is a no trespassing sign.

  (we already have a way to map gates.)



What is the actual problem with other people's driveways being marked
access=private on the map?  yes, driving on is usually technically not
illegal, but unless you are going there because you were invited for
have a reason they'd approve of, it's basically not ok.

If you object to pink dots on driveways, I'd say that access=private is
what is expected so the renderer should be fixed to not show that and
show other access values.


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

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

[Greg Troxel]

Tod Fitch  writes:

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

access=permissive is good when mappers know that the owner is ok with
people using the road.

access=yes is defined to mean that the public has a *right* of access.
A driveway to a a house very definitely does not meet that test.

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.

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.

(OSM's data model is not rich enough to label private with who has
permission when.  That's what is really needed to make this work.)

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.

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

I won't argue that tiger imported data gets this right.  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.  Given our defaults, no access tag is equivalent
to that.  If you can see it is a residential driveway and it is not
signed no trespassing, the two possibilities are:

  A) the owner is truly ok with random usage of the driveway *other than
  for legit purposes to visit or help the owner  ==> acesss=permisssive

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

  C is not a possibilty) The driveway is really legally a public way.
  (Well, anyone can be confused, but public way status can be looked up
  at town hall, making it entirely verifiable.)

When looking at such a driveway, one cannot tell for sure which is the
case of A and B.  But at least around me, it's 99.9% B, and thus "looks
like a residential driveway" is the verfiable backup for access=private.



I can certainly see a case for "access=destination" for these driveways,
with semantics that IF you have a reason to go to the house, you may use
the driveway.  But that's still access=private for the house and
arguably the land, and just moves things around in a way that I think
makes routing and data interpetation harder, and is thus a bad idea.

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

Re: [Talk-us] Heavily-wooded residential polygons

[Greg Troxel]

stevea  writes:

> We agree.  The issues are both around the different behavior of the
> (Carto) renderer when both landuse=residential and natural=wood are
> combined (and there are highly complex ways they can be and are
> "combined" in the OSM database), and around how mappers understand
> these data should be entered.  Should both natural=wood and
> landuse=residential be "stacked" as two tags on one (multi)polygon?

I would say probably not, as it is highly unlikely, really entirely
unlikely, that an extent of landuse=residential, determined by
aggregation of property with similar use, lines up exactly with an area
that is covered by trees.

> That was and is widely done in cases where heavily-wooded residential
> polygons exist, though a "better" trend (at least around here) is to
> break these apart into two polygons: one explicitly on the
> landuse=residential polygon (glom of parcels which are residential, to
> the area extent where they are), one on the polygon defining the
> extent of natural=wood.

Yes, this is sensible.  Two areas, entirely disconnected spatially, each
defining the area where their property applies.

> Unfortunately, Carto doesn't easily (it does consistently, but the
> rules are complex, having to do with sizes of the underlying polygons)
> render these consistently, requiring frequent "fiddling" by craft
> mappers who are looking for both a desired effect and a visual
> semiotic which richly and accurately conveys what is going on: heavily
> wooded residential landuse.

THat's what I meant by suboptimal, which was a polite word: If there is
semantic markup of "this area is residential landuse" and "this other
area is covered by trees", then the rendering rules should do the same
thing regardless of the precise form of the relation/polygon/etc.  It is
a bug if anyone needs to walk on eggshells to make it come out right.

I don't mean in any sense to say "the people that do Carto are bad
people".  This seems incredibly hard to get right and I don't know how
to fix it.  I just mean that it is a failure of software to be ideal and
a place for improvement, in a descriptive and non-judgemental way.

>> The basic problem here is that it's pretty straightforward to render a
>> map that primarily shows landuse, and it's pretty straightforward to
>> render a map tha primarily shows landcover.  What carto does, and what a
>> lot of people want, is a way to show both of them.
>
> I wouldn't necessarily call it a "basic problem," more like the desire
> of "let Carto display both" doing so in complex ways, which gives rise
> to "well, what are the best practices here?"

I think we agree; I'm saying that designing rendering rules that show
land use and land cover at the same time is 1) hard and 2) beyond what
is typical in cartography.  In other words, the "what are best
practices" question you pose don't have an easy, consistent answer.

>> I would suggest that if tagging heroics are needed there is something
>> suboptimal in the renderer.  I think renderers probably need fancier
>> code to choose which of landuse/landcover to emphasisize depending on
>> local scale.  Or a deconfliction of symbology.
>
> Yes, heroics are sometimes employed, yet even that isn't always enough
> (it is often, but not always).  "Suboptimal" might be too damning, as
> I don't think it is "deficiencies" in the renderer, rather I think
> there are "projected expectations" of the renderer (that it appears
> Carto CAN render "both," so it SHOULD, and it DOES, but in
> sometimes-confusing ways).

I don't know if you are just trying harder than me to be nice, or if we
really see this differently.  I see a rendering plan like a
specification, something like "an area that is both landuse=residential
and natural=wood should have a 40% gray fill with a stipple of tree
icons at 20% green" (making that up, details not the point).  Then,
areas that are covered by each should be like that.  And  the exact form
of tagging should not matter, and people should not feel motivated to
mess around with tagging form to make the renderer work.  Otherwise,
it's a bug to be fixed.  Again, this is hard and I get it that people
with limited time are working on it.

> This is an example of amazing, sometimes
> beautiful things going on in the renderer "driving" whether and how
> OSM should and does enter data.  Yes, there is some "coding (data and
> tagging) for the renderer" going on, but it appears to be in the best
> longer-term interests of good data entering, not simply and only for
> the same of "pretty renderings."  I believe we can get there, an
> attempt to discuss "best practices" (I'll settle for "better
> practices" for now!) is a step in that direction.

As always, there is the question of whether people are really coding
tagging for renderer behavior that is not justified, or whether there is
a sensible semantics in between taggers and interpreters.  I feel like
you have arrived at having to walk on eggshells to make it 

Re: [Talk-us] admin_level and COGs, MPOs, SPDs, Home Rule

[Greg Troxel]

Bill Ricker  writes:

> A manufactured armchair consensus, however long on a Wiki, may still be
> wrong on the ground.

This point bears more complicated dicussion, but I think it's clear that
something that was rough consensus in a general sense has been
misrepresented to become a hard rule and a thing with a life of its own.
People may have agreed with the notion that "admin_level is generally
used to represent things in the hierarchy of governments".  Reality is
messy and we are functioning as geographers here.  Part of the issue is
that the US is (almost, AK) entirely divided into counties, and the
federal government considers counties a real thing.  So it is far more
reasonable and helpful to represent all counties the same way, accepting
fuzz on the degree to which they have government (which is highly
variable anyway), than to make a tortuous cut point and declare some of
them non-real.  If somebody wants to have tag for admin_level that's a
scale of 0 to 100 of how real their government is, that's fine.  The
problem is telling some people that their subdivisions aren't real, when
that's not how the locals feel, and it's not how a geographer looking at
the whole US would see it.

(Agreed with your analysis that says "counties no longer exist" is wrong.)

> If we the OSM are the Basemap to the World, not having Counties for CT and
> RI as the same admin_level=6  as all the other states very awkward for our
> downstream users.

A huge point.  We must remember why we are creating a map.

> (My Ward and Precinct do not have elective officers nor staff of
> government, but are accepted as admin_level=9 and 10 respectively; likewise
> Neighborhood admin_level=10, Unincorporated community admin_level=8 need
> not have officers nor staff.)

I was going to point out ward/precint.  My town has two precincts.  They
were created solely because of some state rule that precincts (a voting
thing) cannot be bigger than so many people.  So we have 1 and 2, and an
arbitrary line.  When you get to the single election place, you have to
look at the map, sort yourself into 1 or 2 and go to one or the other
checkin table, go to the matching voting booths, and the matching
checkout table and ballot box.  These totals are reported separately,
for no actual reason and then promptly added.   This is  an artifact of
no lasting value, and I would say 1% as worthy as being mapped as
counties in Rhode Island.   In Rhode Island, people know what county
they live in.  In my town, *I* don't even remember what precint I live
in, and I'm a map nerd and a former town official.

> The CT  "Geospatial Information Systems (GIS) Council" is the strategic
> alliance of producers and consumers of GIS in Conn Govt, in lieu of a
> consolidated GIS department. Their Geographic Framework Data strategy
> 
> [2006/2011] specifically calls *County* an "*Administrative Boundary*" in
> (p.19, excerpted below) ; conversely RPO is listed as a *Thematic* basemap
> (p.12) but *not* named as an "Administrative Boundary" (emphasis on *county*
> supplied):

That's interesting information.


> CODACIL -  RHODE ISLAND
> The situation in RI is the same as Connecticut - the state is still lawfully
> *divided* into Counties
> , but
> there is no *government* at County.
> In fact, RI Counties are slightly *more* real than Conn Counties; RI
> Counties still have County Towns
> .
> (What Mass. and Olde England called Shire Towns. Conn Judicial Districts'
> Court Towns are the same thing under a new name.)

That seems like clear evidence of an adminstrative subdivision.

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

Re: [Talk-us] admin_level and COGs, MPOs, SPDs, Home Rule

[Greg Troxel]

Frederik Ramm  writes:

>
> I didn't even want to weigh in on the discussion, mine was more a
> comment on process. You shouldn't delete something that has been there
> for 10 years and then say "btw let's discuss" ;)

Agreed.  Also, I think OSM has a defer-to-locals notion, and people far
away changing things in CT/RI against the wishes of locals seems not ok.

If the locals talk among themselves and do it themselves, that's
something else.  But so far it seesm everybody from New England (as well
as our neighbors in NY) who has spoken up seems to be in favor of
letting county boundaries stay regardless of how they fall on some
strict definition of government.


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

Re: [Talk-us] admin_level and COGs, MPOs, SPDs, Home Rule

[Greg Troxel]

Anthony Costanzo  writes:

> county. CT's counties have no associated government (anymore) but they
> are still commonly used for statistical purposes and they still have
> cultural relevance as well - you will hear references in casual
> conversations to Fairfield and Litchfield counties. Meanwhile ask any
> Connecticutter what COG they live in and most of them will probably
> answer "what's a COG".

(t's nice to hear from someone in CT, as I have not really understood
things there, expect that it's obvious that the National Weather Service
thinks countries still exist.)

Do you, as a CT resident, have to put down your county of residence on
any government paperwork, either state or federal?

Or is there some notion that if a federal form asks for your county, you
can answer "That's a ridiculous question - CT has no counties" and that
is considered an OK answer?

Do state forms uniformly decline to ask the question about county?

How does jury duty work?  When you are called, how are you sorted into
which courts you might ahve to go to?  If you only have to go to courts
near you, vs the whole state, does that region align with historical
county boundaries?

Does the federal government believe that there are no counties?  Are CT
counties represented on the National Map and in the federal GIS
databases?

Does the state of Connecticut publish maps or geodaata, and do they
think counties exist as an administrative thing between state and town?


(In MA, you are expected to put down a county, and jury duty is along
county lines - but we already established that MA still has counties
after talking about district attorneys, sherriffs etc.)

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

Re: [Talk-us] admin_level and COGs, MPOs, SPDs, Home Rule

[Greg Troxel]

stevea  writes:

> Except, and I don't mean to split hairs needlessly here, a "county" in
> 46 states (or 48 if we count county-equivalents in Alaska and
> Louisiana) isn't the same thing as a county in two (Rhode Island and
> Connecticut).  So, in the above scenario when you describe "using them
> to visualize..." they are not equivalents.  IMO, OSM should delineate
> this, and years ago we evolved a tagging scheme that does so, in the

But we are fundamentally tagging the  wrong thing, even if groupthink
led to consensus.  In the US there is a strong notion of county, even if
CT/RI, and those lines should show up on rendered maps.   Deciding that
the tag that everybody expects to use should mean something different
from what essentially all map users want to know is not helpful.

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

Re: [Talk-us] Heavily-wooded residential polygons

[Greg Troxel]

stevea  writes:

> As I mentioned to Doug I exchanged a couple of emails with
> user:jeisenberg (a principal contributor to Carto) about what was
> going on with some examples of this, and Mr. Eisenberg explained to me
> (in short) that it is a complicated ordering (or re-ordering) of
> layers issue, both Doug and I continue to scratch our heads about what
> "best practice" might be here.  (For "heavily wooded residential"
> polygons, which are frequent in Northern California).  While Doug and
> I both tend towards the preference of the "superimposed look," it is
> not always simple to achieve, due to complexities in the renderer and
> data/tagging dependencies.  And, Doug and I are certainly aware of
> "don't code for the renderer."  However, given that Doug and I are
> fairly certain that others have noticed this, but aren't certain that
> others know what best to do (we don't, either), we ask the wider
> community "what do you think?" and "What are best practices here?"

Agreed this is really hard.

First, I'm going to assume that polygons for landuse=residential do or
are intended to align with property boundaries.  I'm also going to
assume that natural=wood aligns with the actual location of trees, which
is (in mass) almost always not aligned with property boundaries.  I have
thought it an error to have natural=wood tagged on a polygon that shows
conservation land, as the adjacent non-conservation land almost always
similarly has trees (around me).

I would suggest that perhaps a "this land has some trees" landcover tag
(cover != use, strongly agreed) may make sense.  I am not sure you are
talking about this, or not.   I find natural=wood to imply that the land
has none to very little built structures, mostly trees, and the usual
understory plants.   I would definitely not want to use this tag on an
landuse=residential area with houses, but I might use it on the rear
parts of a housing area that are basically trees.   I also would not
want to stop at the subdivision line.

The basic problem here is that it's pretty straightforward to render a
map that primarily shows landuse, and it's pretty straightforward to
render a map tha primarily shows landcover.  What carto does, and what a
lot of people want, is a way to show both of them.

I would suggest that if tagging heroics are needed there is something
suboptimal in the renderer.  I think renderers probably need fancier
code to choose which of landuse/landcover to emphasisize depending on
local scale.  Or a deconfliction of symbology.

To have a way forward, I think we need a coherent design for a style
(not code, but an articulation of how it ought to work, first) that uses
some kind of symbology for landuse and some other kind for landcover.
I naively lean to solid fill, tending to lighter shades, for landuse,
and stipple patterns for landcover.  I think this is what you are suggesting.

It is interesting to think about the 80s USGS topo maps, and surely also
interesting to look at other traditional maps for inspiration.  The USGS
ones were primarily land cover and very little landuse.   But they did
have a gray "house omission tint" in built-up areas, which I'd say is
"this area has many buildings" and is sort of landcover, even though
it's a proxy for landuse.

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

Re: [Talk-us] admin_level and COGs, MPOs, SPDs, Home Rule

[Greg Troxel]

stevea  writes:

>> Also, I don't believe in "states with no counties".  I do believe in
>> "county government dissolved".  Still, the counties as boundaries
>> continue to exist, and remain important, and shoudl still be
>> admin_level=6.  Many times interacting with the government you are
>> required to list your county.  And, almost everyone believes in county
>> boundaries and the notion of knowing which county you are in, even if
>> they don't collect taxes and have employees.
>
> I don't wish to insult you, but in this regard, it matters little what
> you believe.  As long as we agree that the constructs of human
> political institutions "are what we say they are," beliefs really
> don't enter the equation.  There really do appear to be four states
> without counties, though two (Alaska and Louisiana) have "county
> equivalents."  The two remaining (2.5 if we include Massachusetts' 8
> non-counties out of its 14) which really don't are Rhode Island (and
> that's fairly "pure" when it comes to "no counties," they are truly
> geographic in nature, not political) and Connecticut.  The latter
> "dissolved" its counties in 1960, "reformulated 15 RCOGs" (councils of
> town governments with strictly limited function, like landuse
> planning), then in 2014 reduced these to 9 RCOGs.

My point is that in Massachusetts, counties are real in that the
government expects you to know what county you are in, and there are
signs. Many state government functions are lined up with these counties
- it's just that the people are state employees instead.  The federal
government believes in counties - they are used to organize lots of
things even if the counties have no taxing and spending.  So they really
are a political subdivision, even if they have zero government
functions.

We in the Massachusetts local community want to have admin_level 6
relations for these boundaries, and I personally consider deleting them
to be vandalism.

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

Re: [Talk-us] admin_level and COGs, MPOs, SPDs, Home Rule

[Greg Troxel]

stevea  writes:

> Our wiki is a vital source of reference and "how to."  It deserves the
> very best effort we can give it.  Sometimes, especially with a complex
> topic where local knowledge matters, yet so also does learned,
> scholarly perspective, a Discussion page gets wordy and detailed.  I
> do believe OSM wants to get this page as "right" as it can.  Minh and
> I agree there can be "multiple books in the library about (roughly)
> one subject;" the wiki he started on Boundaries is "more
> descriptive"while this one is "more prescriptive."  We walk a careful
> edge.  There are some crafted boundaries (heh) of syntax and
> semantics.  Let's build upon what we've built (with some effort).

I think it's great to record in the wiki established consensus and best
practices.  I think it's unfortunate when things are designed first in
the wiki separate from established consensus, and then later referred to
as representing consensus, like the notion of ele being for ellipsoidal
heights in the Altitude pag.[q

> Greg, the sort of COG Connecticut has built (an RCOG) is unique as
> "COG entity in a state with no counties."  There are also COGs in
> states with counties and I temporarily assume perhaps in states with
> townships, though I can't offer immediately a concrete example.  I
> don't know what numerical value of admin_level we would begin to
> assign to these (we shouldn't assign any, imho, and it seems your
> opinion, too), I have heard 5, 5.5. 6 and 7.  "Collisions with
> existing," hence 5.5.  We started to do this with CDPs at 8 and backed
> that out: they're not these.

I looked up COG> I don't see COG as an admin_level.  They are basically
like some combination school districts and regional planning agenceies.

Also, I don't believe in "states with no counties".  I do believe in
"county government dissolved".  Still, the counties as boundaries
continue to exist, and remain important, and shoudl still be
admin_level=6.  Many times interacting with the government you are
required to list your county.  And, almost everyone believes in county
boundaries and the notion of knowing which county you are in, even if
they don't collect taxes and have employees.

We also have the concept of ward and precinct as admin_levels, and I
have never seen these entities have any government functions.  They are
simply boundaries that determine how votes are counted or which poling
place you go to.  If they are legit as admin_levels, then counties with
no government are much more legit.

> Please, put the boundary in the map if you must and tag it
> boundary=COG and let's be done, please.  No admin_level value at all,
> unless we can tolerate seemingly endless discussion and maybe some
> heated argument, too.  Clifford hasn't the patience as loudly and
> clearly, patience is wearing thin.  If we must continue, let's be
> careful to keep it civil and scholarly if we can.

That's a very good plan.

The basic issue here is that admin_level has to have a clear hierarchy,
and once you talk about 12 kinds of regional things, that is clearly not
possible.

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

Re: [Talk-us] admin_level and COGs, MPOs, SPDs, Home Rule

[Greg Troxel]

stevea  writes:

> The topic is active again at
> https://wiki.osm.org/wiki/Talk:United_States_admin_level#Recently_added_Connecticut_COG_.28Regions.29_as_5_and_CDP_as_10_should_be_deleted
> and seems to need the assistance of seasoned political scientists who
> can say whether a COG in Connecticut, for example, is "a government"
> or not.  (I say a COG/MPO is a LIMITED government, like a sewer
> district, so isn't "really" a "full spectrum" government, therefore
> shouldn't get an admin_level value, as this key associates with
> boundary=administrative).

For what it's worth, I live in Massachusetts, which is next to
Connecticut, and generally pay attention.  I have aboslutely zero idea
what a COG/MPO is, but I think admin_level belongs on state/county/town
and things that pretty much everybody recognizes as admininstrative
subdivisions.  There are school districts, sewer districts, historical
districts, and a ton of other things, that are something else.

I do fear for the future of OSM that wiki editing is such a big thing.

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

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

[Greg Troxel]

Yes, but I mean cases when it is obviously, from imagery and land use, a single 
family house driveway.

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

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

[Greg Troxel]

Dave F  writes:

> On 21/03/2020 20:59, Greg Troxel wrote:
>>
>> This really seems unfair.
>>
>> When someone maps for OSM because they want to, they have goals and a
>> typically a good attitude about community norms.
>>
>> When someone is a a paid mapper, their goals come from the person who is
>> paying them, and they don't necessarily care about the overall health of
>> OSM.
>>
>> So this "paid mapping is a bit scary" notion is 100% accurate.
>
> You've made a leap in logic there. From guessing to 100% true.

No leap, and no guessing.

I have made a logical conclusion about a situation with a structural
conflict of interest.

It is entirely normal in our greater society to recognize conflicts of
interest and to mitigate them.  In open source, we don't talk about it
much, but usually contributions come in chunks and are reviewed.  OSM
doesn't have a review process, really (not a complain - just that
review-before-merge isn't something that can address COI in OSM.

I did not say (and do not mean) any of

  all paid mappers are bad people

  all edits done by paid mappers are bad

My point is that when people are paid to map, there is a structural
conflict of interest between the good of OSM and the goals/incentives
impressed on the paid mapper.  Again, that doesn't mean it's always
misaligned - it means that the possibility is very real, and we
currently don't have a way to deal with this.  So I find the general
situation inherently fraught.

(There's also the issue of misalignment between the good of OSM and the
goals of the employer, but I'm assuming that the employer's goals flow
down to paid mappers goals, for a competent employer.)


>> That doesn't mean all paid apping is bad; were I to take money from
>> the local chamber of commerce to make sure all their businesses were
>> on the map with opening hours and other details, all of it would be
>> done in a way that other mappers would think is correct, or at least
>> just as correct as if I were doing it for fun.  But the idea that
>> people are hired into a position and given instructions might lead to
>> bad outcomes is quite sensible.  Really these edits are not so
>> different from mechanical edits, and I think the organizers need to
>> own the responsibilility for high quality, and the standard should be
>> quite a bit better than normal hand mapping norms.
>
> What's the betting you'd be the first to complain when your parcel is
> 30 minutes after it's allocated delivery time, because the driver
> couldn't find the right driveway.

Now you have crossed into ad hominem and strawmen.

Note that what you quoted from me said "might lead to bad outcomes", not
"always will".

I did not say that anybody, Amazon included, adding driveways following
existing norms was a bad thing.  Around me the average edit quality for
driveway additions has been good -- and I have not complained about
them.  There have been some with not quite right tagging, but mostly
they've been ok, and its been things like "highway=service" without
"service-driveway" -- not egregious, still better than before addition,
but too heavy on the render, as well as not quite right.

My belief is that a bunch of paid mappers with a narrow focus and
basically only adding missing things is quite likely to be mostly ok.
Once you get into changes with more nuance, I expect more trouble.

I did say that when someone pays a lot of people to map, then that
becomes a large scale edit.  Again I didn't say that was always bad --
but I did say that the company needs to be responsible for making the
problems that could happen not happen actually.  I really don't
understand why you consider that to be so offensive.

> This is all AL are doing, completing the final quarter of a mile of
> their journey in areas not easily accessible to the general public.
> It is *not* a mechanical* edit, but taken from on the ground surveys
> using GPS, in *exactly* the same way many voluntary contributors map.

Are you associated with AL in any way?  I'm guessing not, but your
reaction to pointing out a structural conflict of interest is remarkably
strong.

> Please don;t assume, go on the evidence of the contributions. I
> believe they're improving the quality of the OSM database.

My memory of which paid editor did which is blurred, and I think it
wasn't amazon, but in the last year or two I have had to clean up a
number of things where conservation land was touched and local-consenus
tags, put there by local mappers, were removed by far-awy paid mappers.
While I could talk via changeset comment to one paid mapper, another
paid mapper from the same company wwould do something similar; there was
obviously no coordination and no intent to respect local norms and to
interact with the local community.

Th

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

[Greg Troxel]

Dave F via talk  writes:

> 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.
> I doubt Paul, when he started his first *paid* job was an expert at
> it, & never made a mistake.
>
> It sounds like Paul's got his knickers in a twist over something other
> than poor quality data.

This really seems unfair.

When someone maps for OSM because they want to, they have goals and a
typically a good attitude about community norms.

When someone is a a paid mapper, their goals come from the person who is
paying them, and they don't necessarily care about the overall health of
OSM.

So this "paid mapping is a bit scary" notion is 100% accurate.  That
doesn't mean all paid apping is bad; were I to take money from the local
chamber of commerce to make sure all their businesses were on the map
with opening hours and other details, all of it would be done in a way
that other mappers would think is correct, or at least just as correct
as if I were doing it for fun.  But the idea that people are hired into
a position and given instructions might lead to bad outcomes is quite
sensible.  Really these edits are not so different from mechanical
edits, and I think the organizers need to own the responsibilility for
high quality, and the standard should be quite a bit better than normal
hand mapping norms.




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

Re: [Talk-us] Mapping for emergency services

[Greg Troxel]

Mike N  writes:

>> If you consider an urban search and rescue team's mission, and a large
>> scale event, buildings on a map can be extremely helpful for planning
>> and operations where the accountability of many directed searches of
>> structures is imperative.
>
>   That's good information - I sometimes wonder if there's a use for
> buildings in OSM other than GIS queries for average household square
> footage.

In Massachusetts, we have basically full building coverage from an
import several years ago (with a large number of us checking data before
uploading) of LIDAR-derived outlines from MassGIS.  They have been much
more useful than I thought they would be; you can spot missing roads
(not so much now as they've been added) and tell what areas are houses
and what appears empty.  Driveways going to houses can be used for
navigation and now we have addresses on a lot of buildings.  They are
useful for orientation when in the woods and you can see them.


(And agreed that it's great that different people add different things;
around me OSM is the best overall dataset if you don't care about
finding random business POIs.)

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

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

[Greg Troxel]

Michael Patrick  writes:

> There are international taxonomies that define standards for the various
> terms involved in healthcare provision ( like
> *https://www.hl7.org/about/index.cfm?ref=nav*
>  ). These are important for
> many reasons, like Drs Without Borders may draw personnel from many
> countries and integrate with local medical staff. For example:

I'm really glad to see you posting definitions from a relevant
international professional body.   I think in general OSM should pay
more attention to such things.

As I see things around me, there is

  hospital

  urgent care - takes walk ins

  doctors' office group practice in general practice (perhaps as many as
  30 doctors, and may have xray, lab, etc. -- but it's still basically a
  doctor's office in that you make appointments to see your primary care
  physician or someone covering for unscheduled needs)

  doctors' office group practice for a specialty such as eye care

  single doctor's office (or therapist, etc.)

  day surgery center (minor surgery and colonoscopy are popular)

  standalone MRI/CAT-scan facilities

and I don't see any of them called clinic in any meaningful way.  Some
of them may call themselves clinic, but I view this as more or less
content free, in that if they simply didn't self-describe that way,
nothing that mattered would be any different.

So I don't think tagging as clinic is useful, absent a definition that
allows separating from group practice in a fundamental kind of way.

If it's about having xray, lab, etc., it seems obvious those things
should just have extra tags, rather than changing the type.

It's possible that there are things that are sort of like doctors' group
practice in how they function medically but which take unscheduled
patients because of the population they are serving, but I don't see
that as changing the main tag - perhaps it deserves a
walkins_accepted=yes subtag.


I do hear the word clinic used as in

  The [town name] Medical Reserve Corps will be holding a flu clinic at
  [community center] on [date/time].

which means they are setting up to provide immunizations in bulk, but
this is an event, not a place.

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

Re: [Talk-us] Railway improvements; stations vs. halts

[Greg Troxel]

Clay Smalley  writes:

> Over the last few months, I've been doing some systematic improvements to
> the passenger railway network across North America. Much of this has been
> filling out public_transport=stop_area relations for every railway station,
> including stop positions and platforms, as well as verifying the geometry
> of the underlying railways and classifying them (usage=*, service=*). My
> goal here is to prepare the map such that route relations can be more
> meaningful and accurately describe which track each train uses.
>
> In the course of doing this, I got a tap on the shoulder [1] and found out
> I was using a definition of railway=halt that may not match up with what
> people were expecting. As far as I know now, railway=station was originally
> intended for stations where trains are always scheduled to stop, and
> railway=halt for flag stops (aka request stops). In the German OSM
> community, there was a decision made for railway=halt to be used on
> stations that are missing switches, which means trains cannot switch
> tracks, terminate or reverse direction there—a distinction more relevant to
> railway operations and scheduling. Naturally, there are quite a lot more of
> these than flag stops.
>
> I'm in a predicament here. So far, I've mapped all Amtrak stations and
> various commuter rail stations across the Northeast according to the
> no-switches definition of halt. I'm happy to revert these back to stations
> (wherever they aren't flag stops), though I'd like to hear others' thoughts
> before going through with that.

I find the notion that "no switches -> halt" notion bizarre and brand
new.  So I would very much be in favor of you going back to what I
consider a normal definition.   I'd say that's railyway=halt if there
are *no* scheduled stops.

Around me, the commuter rail has mostly what I'd calls stations:  fixed
infrastructure for trains and scheduled stops.   There are a few places
that are called "flag stops", but that really means:

  train stops if a passenger on the train asks, or if people are visible
  on the platform

but typically such places have some trains alwys stop and some treat
them as flag stops.  So I think they ar railway=station.



I would say if people want to tag absence of switches/etc. that should
be some train-nerd extra key.  This is not relevant to people or routers
using the data.

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

Re: [Talk-us] Jefferson Notch Road and latest "GPS made me do it" in the news

[Greg Troxel]

Tod Fitch  writes:

> In the California Sierra Nevada I tagged a couple of roads with:
>
> conditional:access=“no @ (Nov-May)”
> note=“Seasonal closure from first snow until spring, see CalTrans website for 
> status”
> website=“http://www.dot.ca.gov/cgi-bin/roads.cgi”
>
> With the barrier=gate at either end of the seasonal section tagged with the 
> same conditional:access and note tags.
>
> In retrospect, I probably should have used a description tag rather than a 
> note tag for the descriptive text.

Agreed on description vs note.  My impression is that note is appopriate
to communicate something to future mappers, when the intent is to have
them improve it and remove the note.  Perhaps I only feel that way
because OsmAnd shows note= and fixme= when osm editing support is turned
on.

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

Re: [Talk-us] Alt_names on counties

[Greg Troxel]

stevea  writes:

> Also, I find that "alt_name" works well for abbreviated county names,
> as in California in certain contexts, the name of a county without the
> word "county" appended unambiguously communicates a geography to
> someone.  (As in "From this part of Amador (county), you'll have to
> skirt the edge of El Dorado to get to Alpine").  Greg (M.) seems to
> indicate this happens in (Pima) Arizona, as well.

I can see that this is useful, but I see that as "how should a
renderer/router/searcher use the database", vs "we should add alt_foo
tags for anything that  someone might search on".

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

Re: [Talk-us] Alt_names on counties

[Greg Troxel]

Tod Fitch  writes:

> I’ve noticed that a number of counties in California and Arizona have
> what seems to be unneeded alt_name tags in their boundary
> relations. For example Pima County, Arizona has name=“Pima County” and
> alt_name=“Pima”. Same for Pinal County in Arizona and Riverside,
> Orange, Kern and Ventura counties in California. But this does not
> seem universal as the few counties I looked at in Washington state
> have only a name=* tag (e.g. name=“Columbia County”).

This seems bogus and feels like tagging for the search engine.

I think the root of the problem is that from some point of view, the
name of Foo County is Foo, just like the name of Town of Bar is Bar.


> I don’t see a wiki page for the standard for this in the United States. Is 
> there one I’ve missed?
>
> Assuming there is not standard for this, should there be? And what should it 
> be? (My preference is to remove an alt_name that is simply the name without 
> “County”.)
>
> For what it is worth, it looks like the alt_names for counties in Arizona and 
> California were added in 2014 by the user “revent” who is still actively 
> mapping borders around the world.

Definitely ask them about it, and if they aren't local, and the locals
don't like it, fix it.   (Is there a talk-us-califoria list?)

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

Re: [Talk-us] Trunk VS primary,

[Greg Troxel]

Paul Johnson  writes:

> On Tue, Dec 17, 2019 at 7:24 AM Mike N  wrote:
>
>>
>>I think many of the trunk VS motorway VS primary conflicts come from
>> 2 points of view:  on the one hand, people like to zoom out and see a
>> coherent network of interconnected roads.
>
> In which case, rendering based on network on the route relations would be
> more appropriate.

This is the crux of the matter.  Calling things trunk so they render is
tagging for the renderer in a bad way.

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

Re: [Talk-us] Alaska Highway AK-2 tagging

[Greg Troxel]

Bradley White  writes:

> The lack of consistent highway tagging in the US is one of the biggest
> sources of frustration with this project as a whole to me. IMO, the US
> community needs to make a decision to *either*:
>
> 1. Use 'trunk' to mean "major cross-country highway" and orthogonalize
> expressway constructions with its own 'expressway=*' tag, bump
> 'primary' to "minor cross-country highway/major regional highway",
> 'secondary' to "minor regional highway/major local road", etc...
>
> Or:
>
> 2. Use 'trunk' to mean strictly "partially grade-separated limited
> access divided highway" (with explicit instruction to not tag singular
> or isolated interchanges as 'motorway')
>
> The mixture of the two schemes that leans towards one or the other
> depending on what part of the country you're in is inconsistent and
> confusing to me, and judging by how many times we've gone in circles
> about this on us-talk, others as well.

Agreed.  I think option 2 is the right path.  primary used to mean
important long-distance route, before people started calling local roads
primary.

Long term, it would be nice to separate these notions and have some
highway:importance key for that, and leave the road type notion that
separates primary/trunk/motorway alone (or move it to some other tag,
and get rid of highway=trunk and highway=motorway).

As for the freeway/expressway notion, note that this is regional
langauge and we don't walk that way in Boston (we're too busy running
red lights and using our horns!!).  But seriously, I don't know those
distinctions and people don't really use those words.

I guess you are suggesting to add highway=expressway to have expressway
mean "sort of motorway but not quite" and change trunk to be "very
important".  I am afraid that with so much established tagging the only
reasonable approach to orthogonalization is to adopt two new tags for
the things in question and deprecate the old way, allowing for a long
and messy transition.

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

Re: [Talk-us] Alaska Highway AK-2 tagging

[Greg Troxel]

Tod Fitch  writes:

> My reading of the wiki indicates that for the United States a trunk is “a 
> high speed Arterial Divided highway that is partially grade separated.” [1]
>
> What is the problem with having the main road between regions/cities/towns 
> being “primary”? Do you like the rendering of trunk better?
>
> For myself if I planned a driving trip and was expecting a trunk road I’d 
> sure be surprised to find areas that are undivided and apparently, from other 
> responses in this thread, unpaved in sections.

Agreed.  To me trunk means:

  paved
  divided
  very few at grade intersections or driveways (one every few miles is ok)

basically "sort of like a motorway, but not quite".

primary already means "this is a very main road".

There are plenty of primary roads with 65 MPH speed limits out there.
If they aren't divided or have more-than-occasional at-grade
intersections or driveways, that's the right classification.

I don't think a road that isn't physically trunk should get tagged as
such just because it is the most important road (or the only road).

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

Re: [Talk-us] Mapping rail trails

[Greg Troxel]

Thanks for the nice summary.  I have one minor issue to raise a question
about:

stevea  writes:

> As for rail trails, very nice work, Richard!  Rail trails are usually
> classified as local (lcn) if they are for cyclists, although some are
> sponsored at a state-level: these are properly tagged rcn (regional
> generally means "state-level" in the USA).  I don't know this for sure
> (Minh?) but I might imagine that the C Canal Trail over and above
> the USBR 50 relation might be properly tagged rcn instead of lcn.
> Such decisions are best determined with more-local consensus by
> Contributors who are familiar with the local / state statutes which
> define the route.  The Bicycle_Networks wiki describe (MUTCD-standard)
> signage for NUMBERED routes which disambiguate the network-level tag
> that should be used.  For routes which happen to be signed
> on-the-ground as non-governmental (non-MUTCD-standard signage), please
> consider these on a case-by-case basis, starting (as Richard did) at
> the local (lcn) level.  If network=rcn is actually a better value,
> this is likely to emerge with strong consensus at a more-local (state)
> level within OSM.

The notion of state sponsorship is interesting, and there is the aspect
of a state bicycle route number, akin to a state numbered highway.  I
can certainly see that being rcn.  Then there is the aspect that in MA,
most things called "rail trails" end up getting built with state funds,
and built to state construction standards, both avoiding the towns
having to say and making the resulting trail much more costly (but nicer
in some ways).  These trails tend to have names, like "Nashua River Rail
Trail", "Assabet River Rail Trail", "Bruce Freeman Rail Trail", but they
don't have a "MA Bicycle 29" designation, or if so nobody knows that.

Most of them go over fairly short distances; the Nashua River one is
about 12 miles and is in the towns of Ayer, Groton, Pepperell, MA and a
bit in Nashua, NH.  To me, that feels local in scope rather than
statewide, so I'd want to see it as lcn.  The fact that it was funded
with state rather than local money doesn't seem important.  (Actually,
state money pays for local roads in complicated scheme.)

Now, if the Central Mass Rail Trail were somehow complete in a Cambridge
to Northhampton sort of way, or even half of that, it's obviously rcn,
regardless of who organizes it.

This gets fuzzy.  Perhaps, in a US-centric northest-centric way, it
feels like rcn is 100 km.

I'm not sure this ended up being useful.  I think I more or less agree
with where I think you ended up, saying that other than federal and
state numbered routes, all routes are lcn, unless there is really clear
local consensus that they are very important and of state-level scope,
in which case they can be promoted to rcn.


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

Re: [Talk-us] Mapping rail trails

[Greg Troxel]

Richard Fairhurst  writes:

> Hi all,
>
> You might remember that back in March I wondered whether we could get
> access to the Rails-to-Trails Conservancy's data, which they've given
> to Google:
>
> https://lists.openstreetmap.org/pipermail/talk-us/2019-March/019266.html
>
> Helpful people on this list followed that up with RTC (thank
> you!). Finally the answer has come back and it's no. The data is
> apparently "free as in Google" - sadly RTC aren't interested in having
> their trails appear in basically every single cycling app which uses
> OSM data.
>
> (In completely unconnected news, I note that RTC currently sells
> "TrailLink Unlimited" mapping for $29.99/year.)

Thanks for pushing on this and telling us what the results were.

One wonders how RTC squares this decision with their legal obligation to
act in the public interest.  Not sharing data at all to get "related
income" to fund their operation is one thing, but sharing with Google
while not with OSM seems hard to defend.

My impression is that for many of the US rail trails, perhaps most of
them, RTC has no real involvement (in ownership or construction), so
"their trails" is perhaps "the set of trails that are in their
database".

Agreed that making OSM the better database is the only good trail
forward.

___
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

[Greg Troxel]

Jmapb  writes:

> 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

Agreed.

> frequency is entirely up to individual apps. For OSMAnd, I think it also
> depends on what version you're using.

Normal OSMAnd usage has maps generated at the end of every month,
available on about the 10th of the following month.

OSMAnd has a second mode "live", where you can get delta updates from
your last full map, at intervals up to hourly, and in particular on
demand.  You can then see the time of update, and the time of last map
change.  If I update, I typically see a last map change within about an
hour, maybe a bit longer, and usually when it's longer (at 6am, it might
be last evening) I suspect there were no edits overnight.

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

It's true that this likelihood exists, but I would argue that users of
OSM data should have a plan to get users fresh data reasonably often
(longer than 6 months does not seem respsonsible).  I do not think we
should design for systems that are not attempting to get reasonable
freshness.

I have observed over my 10 years in OSM that the typical update cycle
has shrunk, and in many cases when it gets to a month it doesn't shrink
much more, usually.

With OSM, there are no licensing reasons not to update; it's about
transfers of large files vs freshness.  And then there's delta updates,
which osmand does.

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

Agreed.   Around me, hard to predict.

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

Indeed that we don't have a consensus perfect approach.

One should also consider the relative merits of

  road is closed and router thinks it is open

  road is open and router thinks it is closed

typically, an open road that is marked closed is not the only way, and
reasonable routes will be chosen.  As opposed to a closed route that is
marked open, the user will be routed to it and hit a detour.   So I
think "some apps (especially those that have too-long update cycles)
thinking it is closed for a long time" is not a big deal, because 1) it
doesn't hurt much and 2) those apps should shrink their update cycles.

Personally I have come to view 1 month as the longest reasonable update
time, and if a road will be closed for 30 days or more, and I get around
to it, I edit it in OSM.   Overall I tend to optimize for those who are
making the effort to have fresh data, as I think that's where we are
heading, and it meets people who are trying halfway.

___
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

[Greg Troxel]

brad  writes:

>>> Why not simply call anything which is a 'large public area for
>>> recreation', a park, and specify it additionally with additional tags?
>> Because we have existing norms, and it is not generally a good idea to
>> ask that tagging of thousands of objects be thrown out and redone.
> OK, but I think that's what you're asking for if county parks, state
> parks, and large city parks can't be tagged as parks.

If people in one country have mistagged things, then I think it's ok to
fix that.  I don't think it's ok to ask the rest of the world to change
to accomodate our mistagging.

The notion of what leisure=park means (that many "state parks" aren't
included) has been clear to me for years, from reading the wiki when I
joined OSM.

But I'm not really clear on the total statistics of use of leisure=park
in the US and not in the US.


___
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

[Greg Troxel]

Andy Townsend  writes:

> With regard to British English usage, I think you're
> correct*. Something described here as a "park" would pretty much match
> the current description at
> https://wiki.openstreetmap.org/wiki/Tag:leisure%3Dpark (without the
> urban requirement, but you've already talked about that).  In the UK a
> "national park" (or something like the Pentland Hills Regional Park
> which was already mentioned) isn't really a subset of "park" in any
> way - it's something else altogether.

So it seems that the definition of leisure=park we have converged on in
the US matches more or less leisure=park and what humans mean when
speaking en_UK.  That seems like a very sane place to be.

___
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

[Greg Troxel]

Joseph Eisenberg  writes:

> On 4/29/19, Greg Troxel  wrote:
>
>> With leisure=nature_reserve, leisure=park, golf courses, cemetaries,
>> schools, etc., we represent them on the map by some kind of shading or
>> fill.  But, boundary=protected_area is represented by denoting the
>> border, and this does not serve map users well.
>
> If you are talking about the Openstreetmap-carto style (the standard
> map layer on openstreetmap.org), then this is not quite correct.
>
> It's true that leisure=park and golf courses are represented by a fill
> color for the whole polygon.
>
> However, leisure=natural_reserve, boundary=national_park and
> boundary_protected area (with protect_class  1 thru 7 and 97-99) are
> currently rendered identically, with a green semi-transparent outline.
> (There is also a semi-transparent green fill at low zoom levels).

Sorry, I was off on nature_reserve.   But my point is that we have fill
sometimes and sometimes not, and that focusing on thinking about
boundary seems to lead to not filling, and I think that's unfortunate.

It's at high zooms that I think the fill is needed; some of these are
large enough that zooming in means the border isn't showing.

> Military areas and tourist areas (zoos, theme parks) are also rendered
> with outlines in red and purple.

Military at least also has a fill pattern, so they are not just
observable from the edges.  I have no problem with special edges; my
complaint is the decision that no fill is necessary.

___
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

[Greg Troxel]

brad  writes:

> It seems that plain language can be used here, and from the Oxford
> dictionary, a park is:

No.  Plain language cannot be used to define what tags mean.  Each tag
is actually a codepoint, not human language, and needs a definition.
That is fundamental to how tagging works in OSM.

> Why not simply call anything which is a 'large public area for
> recreation', a park, and specify it additionally with additional tags?

Because we have existing norms, and it is not generally a good idea to
ask that tagging of thousands of objects be thrown out and redone.

___
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

[Greg Troxel]

Kevin Kenny  writes:

> The smaller state parks - the thousand-acre type that you contemplate
> - are often not what IUCN considers to be protected areas, and so I've
> taken to using protected_area tagging, but with protection classes
> such as 21 (which woud be accompanied with
> 'protection_object=recreation').  That doesn't render, so as a
> stopgap, I've been tagging them 'leisure=nature_reserve' or
> 'leisure=park', whichever seems to fit, recognizing that further
> developments are likely eventually to make the dual tagging
> unneccessary. https://www.openstreetmap.org/relation/6442393 is
> typical.

I completely fail to understand why IUCN protection status has become
the main thing.  Whether something is functioning as a park now seems to
me to have nothing to do with long-term legal protection.   I am not
objecting to tagging the legal status.  I just don't see how denoting
legal status somehow removes the need to describe what is.

> What I struggle with is are more complex situations - that may always
> necessitate some 'abuse' of tagging. The thousand-acre park with a
> forty-acre developed section is handled quite nicely with your scheme.
> When you have a 'park' comprising hundreds of thousands, or millions
> of acres, operated in public-private partnership, things start to
> break down. This is true of New York's two huge parks; of the USA's
> larger National Parks; and of US National Monuments, National Forests,
> and BLM recreation lands. The outer ring - the legally designated area
> - may not really enclose anything recognizable as a 'park', while the
> stricter 'park' land management may be somewhat diffuse, in many
> discrete protected areas. The larger area is also protected, but
> limited sustainable development is often permitted.

Agreed this is messy.  I meant merely to broach the notion of tagging
usage in sub-parts separately from tagging the name of the entity on the
large object.

> Looking at the IUCN definitions, the only class that fits these large
> parks is '2' - 'national park'. IUCN, like our Wiki, doesn't actually
> require that 'national park' be constituted by a national government.
> It simply embodies a hidden assumption that only a nation-state has
> the resources to constitute one. leaving the bigger state-defined
> facilities in terminologic limbo.

I would ask if it's really a good thing that OSM has adopted IUCN as the
basis for what is and is not a park.  It seems to me that it's causing
trouble.

> Another odd case that I've mapped a lot of are the undeveloped
> recreation areas owned by New York City to protect its water supply.
> The city bought them to protect them from development, and allows
> public access (in some cases requiring that the user apply for a free
> permit, in others, "come one, come all!") I've tagged these with
> boundary=protected_area protect_class=12 protection_object=water, and
> then added leisure=nature_reserve as a rendering stopgap (because
> class 12 doesn't render either).

We used to have "landuse=reservoir_protection" (although maybe these
places are watershed protection, not reservoir).  Part of what I object
to about the IUCN hegemony is the view that everything should be turned
into some complicated protect_class and other tagging removed.

But, in this case, your approach seems reasonable in terms of denoting
the landuse.

I would argue that if people are welcome, then in addition to whatever
protection tags, it deserves "leisure=nature_reserve" *also*.  There is
no reason to conclude from "water protection" that humans are or are not
allowed.  Near me, there is reservoir protection land, and it has "no
trespassing - public water supply" signs.  I think the protection
tagging ought to match your case (but maybe protection_object=reservoir
instead of =water), but also access=no and definitely no nature_reserve.

(I agree with your notion that free permit means access=yes to first
order.)

> One reason that I disfavour 'leisure=park' is, simply, the renderer.
> (I know, don't tag for the renderer!) The objects that render with
> borders (nature_reserve, national_park, protected_area for classes
> 1-6) don't obscure landcover, so those who wish to map landcover in
> these large areas can do so without collision. The only place where
> I've really tried to do that has been Bear Mountain - where I was
> producing a detailed map for a group outing a couple of years ago. I
> didn't push beyond the specific area that I needed.
> https://www.openstreetmap.org/relation/6467468

There is a much larger issue in the standard style between landuse and
landcover, and not having an integrated vision for which is rendered
how, to avoid colliding.

Around me, golf courses have a color fill and nature_reserve doesn't,
and that has always seemed broken.

___
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

[Greg Troxel]

One of the things that has come up is "mixed-use parks", where an area
is not clearly one thing or the other.  I see two kinds of cases (with
of course a blurry line between the cases).

One case is an area where there are two kinds of uses close together, in
a way that's hard to draw a sensible line.  More "this place is both"
than "there are two places near each other treated as the same name".
Consider a smallish area that is both leisure=park and
leisure=recreation_ground.  Assume there is some grass with paved paths,
perhaps some flowers, a few trees, and an area with picnic tables,
perhaps with some roofs, and some charcoal grills.  That's clearly
leisure=park.  Then add a pond with swimming and a bath house for
changing.  Or two soccer fields.  Those by themselves are
leisure=recreation_ground.  Assume that this area is one parcel, managed
as one entity, and named as one thing by the owning body.  So how to tag
it?  Here, I would argue that one should simply look the more
significant use, and pick that and don't worry.  I would lean to park
when on the park/recreation_ground line, because the sports fields will
be tagged as pitches, and once those are there, they are rendered and
findable, regardless of the overall area being tagged as
recreation_ground.

The other case is a large area with subareas that are each clearly one
or the other.  Consider:

  1000 acre parcel, almost entirely forest in a natural state, with dirt
  hiking paths

  a 40 acre sub-piece of this on the edge, that is different:
- paved parking lot
- visitor center / bathroom building
- grass and a few trees (city park like)
- picnic tables, grills

  probably there are different rules for the two pieces.  Dogs might be
  allowed in the 40-acre chunk, but not in the larger forest, for
  example.

  the entire thing is called "Foo State Park", owned by a state
  government.  Legally it is one parcel, and run by the same state
  agency.

I think the basic issue is that we tend to focus on the larger
definition of area and think we must give it one tag, so we frame the
question: "Is this 1000 acre place a =park or a =nature_reserve?".
Stepping back, I see a park and a nature_reserve as separate and related
things.

So, I'd be in favor of having a way on the parcel boundary, and another
denoting the park-type sub-piece, calling those outer and inner and
tagging:

 outer: name="Foo State Park"
 inner: leisure=park
 relation wtih outer/inner: leisure=nature_reserve

Or, perhaps not having a relation and putting leisure=nature_reserve on
the outer, with the expectation that renderers/etc. will resolve the
overapping landuse to the smaller geometry.

(As I see it this applies to many National Parks too, but we don't worry
about that because we just call them national_park.)

___
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

[Greg Troxel]

Jmapb  writes:

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

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

THe issue is that leisure=playground does not mean "kids do play here".

It means instead:

  This is a place that has been established as a place to play, and is
  maintained in such a way that such activities are reasonable.  It is
  more or less open to the public (or perhaps associated with a school
  or other facility, or gated community, etc. for exclusive use of their
  people).  It is almost certainly known as a playground or similar to
  those living in the area.

That excludes play sets in back yards, and places where kids go in the
woods in an ad hoc or against-the-rules manner.

It does mean that leisure=playground access=private is going to happen,
in gated community-ish places.  But that's fine, I think.

___
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

[Greg Troxel]

OSM Volunteer stevea  writes:

> It may be emerging that tagging boundary=protected_area (where
> correct) where leisure=park now exists and we delete it, begins to
> supersede leisure=park on many North American now-called-parks.  I
> think that's OK, maybe even overdue.  To be clear, there are plenty of
> "we now call them parks" which are more like protected_area boundary
> areas or maybe "it is what it is today, nothing more."

I think you are not saying that a proper leisure=park should be
protected_area, but that some things which are really protected_area are
mistagged as park.

Here I will mostly talk about leisure=nature_reserve sorts of places, to
include national_park sorts of places that would be
leisure=nature_reserve if we didn't have national_park tags.

I have two problems with the notion of boundary=protected_area:

1) The current landuse is one thing, and legal protection for the future
is another.  Just because something is a nature reserve now doesn't mean
it has legal protection.

A town might own 300 acres of woods, have hiking trails, and have it
signed as "Foo Conservation Area".  That's enough to tag it
landuse=conservation (because that's the current actual landuse) and
leisure=nature_reserve.  But, 20 years from now, they might sell that to
a developer to buy some other land which has conservation value and
enough upland to build that new schoool they want.  So in this case
boundary=protected_area is completely inappropriate.

2) boundary=protected_area is semantically confused, because what is
being tagged is not the boundary, but the status of the area within the
boundary.

Of course, there is a computer-sciency duality between a boundary and
the area within the boundary.  From this viewpoint, things are entirely
equivalent.  But, humans interpret tags other than according to the
strict tagging definition semantics, and they tend to treat
boundary=protected_area as being about the boundary, particularly in
rendering.

With admin boundaries, there is a sense of "the land inside is in this
town", but we have a long cartographic culture of drawing lines on the
map.  These separate towns and states, for example, and it's understood
that this is a large feature and that shading them is not that useful,
except on small-scale maps where there is arbitrary coloring to
visualize that.

With leisure=nature_reserve, leisure=park, golf courses, cemetaries,
schools, etc., we represent them on the map by some kind of shading or
fill.  But, boundary=protected_area is represented by denoting the
border, and this does not serve map users wel.

> I think the greatest thing to "shake out" of this so far is that the
> leisure=park tag can (and should be) frequently be dismissed in
> preference to boundary=protected_area.  This alone will assert a great
> deal of sanity back into things around here.  Whether we invent a tag
> called proto_park ('cause there are such things, the city council just
> hasn't budgeted or spent the money to build it into a more fully
> human-leisure-place, yet).

There is no sanity in boundary=protected_area!  There would be in
area_protected=yes, if it were only used to describe areas that actually
have legal protection (easement or conservation restriction, state or
national And).

That aside, I think favoring boundary=protected_area for parks is a
major step backwards from separating separate concepts.  What is on the
ground, and what the legal protections are against change, are separate
things and should be kept separate.

Arguably, National Parks are no more protected than a parcel of woods
owned by a town (absent any CR/easemetn/state conservation status)
because the owning body can change the rules in the same manner.

In contrast, formal conservation land owned by towns in Mass requires
permission of the state to take out of conservation status.  And there's
the NY example, where the state government can't change things via
normal law.

But, it comes down to "how hard would it be politically", and that's not
really that useful.

___
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

[Greg Troxel]

The real problem is that we have two linguistic traditions: one is plain
langauge, and one is tagging tokens.  People keep blurring them, and of
course this is going to continue.  We end up with having to explain
"Just becuase it says 'Foo Park' doesn't mean it's a park."  If we had

#define LEISURE_PARK0x451

and we were talking about if something were a LEISURE_PARK then it would
be clearer about plain language vs tagging tokens.

OSM Volunteer stevea  writes:

> So, what emerges is that going forward, leisure=park is as our wiki
> describes it (a smaller, urban-scale, human-sculpted place for
> leisure/recreation), EVEN THOUGH many areas which aren't this are now
> tagged this way.

I think that's a correct assessment.  Except that we have to be careful
about "recreation" -- a place that is largely soccer and baseball fields
is recreation_ground.  If you mean walking around, then agreed.

In Massachusetts, I'd say an interesting data point in distinguishing
"park" vs "nature_reserve" is that in a park you are not that likely to
pick up ticks (ixodes scapularis), and in a nature_reserve it is very
likely.  But that's just a proxy for "sculpted" vs "natural".

> Going forward, NEW "parks" (in the USA) get this tag only as it is
> meant/now wiki-described, as we use the Existing 4 more properly.  In
> other words, it is correct to use the Existing 4 INSTEAD of solely
> leisure=park when appropriate.  Simultaneously, it is inevitable that
> many now-tagged-leisure=parks will have that tag changed to one of the
> other Existing 4.  Yes?

I don't really follow "going forward" and "inevitable".  If you mean:

  We the mailinglist more or less agree, to the extent we ever do, that
  things that don't meet definition above  should not be leisure=park,
  and we should tag those things appropriately, both for new objects,
  and people fixing old objects.

then that sounds right.

Another question is: If we didn't have the special national_park tag,
how would they be tagged?  I would say that most would be
leisure=nature_reserve overall, with perhaps some small segments as
leisure=park, and then a few messy cases (Dry Tortugas, maybe Mesa
Verde).  I don't seriously expect us to get rid of the national_park
tag, so that's a moot point.


___
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

[Greg Troxel]

OSM Volunteer stevea  writes:

> How much consensus IS there for tagging national_park on "large,
> (important?) state parks" which roughly (or not) meet the
> national_park definition in our wiki?

My view is that we should deprecate the national_park tag entirely, and
end up with tags that represent what something is and who
owns/administers it separately.  And generally separate things that are
sane to separate.

Plus, I really doubt that what gets called "national park" in various
countries is the same definition.

___
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

[Greg Troxel]

OSM Volunteer stevea  writes:

> I'll try to be brief, but there's a decade of history.  The
> leisure=park wiki recently improved to better state it means "an
> urban/municipal" park, while boundary=national_park (or perhaps
> leisure=nature_reserve, maybe boundary=protected_area) works on large,
> national (and state or provincial in North America) parks.  As the
> sharper wiki focus means a "city_park" (a sometimes-found park:type
> value, I've written brand new wiki on park:type) certainly qualifies
> as a leisure=park, this leaves county_parks (and their ilk, like
> county_beaches) in a quirky "how best do we tag these now?" quandary.

I think Kevin has it right that we should tag primarily by something
about land use, not by owne/operator, although it's fine to tag
operator.

I think the entire "national_park" tag is unfortunate, as it wraps up a
lot of concepts that vary by country, and makes people understand things
when they don't.  In the US, it should mean "preserve the land while
allowing access and enjoyment", there is a notion that the place is
relatively distinguished, and it doesn't really have a connotation of
size.

While "urban/municpal park" and "(USish) national park" are two things,
there is another kind of thing, which I label conservation land,
typically not so urban, and not wilderness.

Around me, there are a number of places, some tens of acres, some
hundreds, where there are dirt hiking trails, some blazes, and some
crude parking areas, and that's about it.  If anything, these are
closest to US national parks in concept, except that preserving the land
is a higher priority than allowing human enjoyment.  I tag them
as landuse=conservation leisure=nature_reserve.

> I can see tag leisure=park persisting on a lot of county_parks for
> some time (forever?), yet it seems OSM's worldwide view of "park"
> excludes them (and we tag boundary=national_park on state and national
> parks).

I don't understand this.

As I see it OSM's "park" is about an area that is relatively manicured
and taken care of, certainly green compared to pavement, but not really
in a natural state.  As in: if all the humans walked away and you came
back 10 or 20 years later, how different would it be?  A city park would
look totally different, and the semirural conservation areas would look
much the same except the trails would be indistinct and have trees
fallen across them.


I would expect US counties to have both city parks (think Central Park
in NY) and things that are almost wilderness areas or wildlife refuges,
plus everything in between.  I don't see level8 vs level6 management as
important (or even level4 or level2).



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

Re: [Talk-us] Monterey - Santa Cruz County line in Monterey Bay

[Greg Troxel]

Martijn van Exel  writes:

> You are correct. The official Monterey County GIS file from [1] has
> the boundary at the shoreline, whereas OSM has it going out into the
> ocean, see https://imgur.com/a/aCMROQZ 
> (OSM in orange, Official GIS in dark gray).
>
> I don’t know all coastal counties have their official boundaries at the 
> shoreline, but OSM has them all reaching into the ocean. [2]
> I also don’t know if there is some convention in OSM (US) to have
> coastal country boundaries match up with the higher level boundary. If
> there is perhaps we may need to revisit?

This is tricky business.

Generally, the jurisdiciton of the state seems to go to 3 nmi (east and
west coasts).  However, whether those state lands are in any town or
county is an interesting question.

https://coast.noaa.gov/data/Documents/OceanLawSearch/Summary%20of%20Law%20-%20Submerged%20Lands%20Act.pdf
http://maps.massgis.state.ma.us/czm/moris/metadata/moris_sla_arc.htm

In Massachusetts, towns and counties do include the state lands.

I would recommend looking up California law and asking this question in
particular.

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

Re: [Talk-us] Trunk versus motorway

[Greg Troxel]

Bryan Housel  writes:

> Can’t a motorway begin or end at an at-grade intersection though?

Certainly, and I think the question is how long does a stretch of road
that meets motorway specs have to be to be tagged motorway.  The basic
issue is that "not having at-grade intersections" is not a local
property of a road, and is really a statement about the road before and
after where one is talking about.

Assume an infinitely long road, divided, 2 lanes each way.  After a very
long time of no intersections, assume an at-grade intersection, and call
this coordinate 0, expressed in km.

Then, assume an another at-grade intersection at 0.100.  After that, at
0.110, and so on, with each being 1.1 times the previous.

By the time you get to 500 km between at-grade intersections, the
intevening roads are surely motorways.  At 100m, they surely are not.

In my view, to be tagged as motorway, the length of qualifying roadway
has to be long enough so that it feels like it is very long, as opposed
to a lucky 2 to 3-mile stretch of trunk that happens not to have any
intersections.

Overall, I would throw out that if a section that meets motorway specs
isn't at least 10 miles, it's still really nice trunk, and should not be
tagged motorway.  Maybe 10 is too much and it should be 5 mi, or 10km,
or maybe it should be 20 or 25 km.   But 1-2 miles is way too short to
flip back and forth.


I have no  idea if this supports or opposes Paul in this case :-)  But
I'm guessing it supports...

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

Re: [Talk-us] Population during mandatory evacuations

[Greg Troxel]

Richard Fairhurst  writes:

> Minh Nguyen wrote:
>> Following some discussion about this changeset in OSMUS 
>> Slack [2], I started a discussion on the wiki about preferring 
>> more stable population figures over supposition about 
>> temporary circumstances. [3]
>
> It's roughly analogous to a situation we had a few months ago with road
> closures due to Hurricane Florence:
>
> https://twitter.com/richardf/status/1040931194999898114
>
> I think the answer is that temporary situations need temporary (i.e.
> lifecycle-bounded) tagging. Tagging temporary situations with unbounded tags
> is ok for those browsing osm.org or another online slippy map with minutely
> updates, but not for anyone using offline maps, sites with less frequent
> updates, and so on.

That is a real issue.  The offline/online distinction is messsy, as you
say, because of the various update times.  I use offline mpas, but tend
to update every few days (osmand live).

But I see population as fundamentally different; the population doesn't
change during an evacuation, and we don't have a tag for "how many
people are currently within this boundary", which is the value that does
change (and changes dailly due to commmuting, etc.).  If someone were
studying things like this and somehow had a graph of the number of
humans within some administrative boundary by hour, they would certainly
not label the y axis "population".


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

Re: [Talk-us] Population during mandatory evacuations

[Greg Troxel]

Minh Nguyen  writes:

> (Crossposted to the talk-us and tagging lists.)
>
> Due to the ongoing Camp Fire in Northern California [1], the place POI
> for the town of Paradise got tagged with population=0 before the
> change was reverted. Following some discussion about this changeset in
> OSMUS Slack [2], I started a discussion on the wiki about preferring
> more stable population figures over supposition about temporary
> circumstances. [3]

That's really unreasonable that somebody would do that.

Obviously population is the number of people whose residence is in a
place, or something like that, not how many people are there this
minute.

It does get tricky for communities that have year-rounders and summer
people, where "residence" is blurry.  But everybody leaving for a week
does not change the population, just as people showing up for a parade
for 6 hours does not etiher.

On top of that, the idea that it's 0, between emergency people and
non-compliant people, does not in general seem credible, and if the
person making the edit was not actually there and able to judge this,
they're out of line on that basis too.


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

Re: [Talk-us] California is too big ;)

[Greg Troxel]

Luis Villa  writes:

>> My guess is the only split that the majority in the state would instantly
>> recognize would be “Northern California” and “Southern California”. However
>> exactly where that split occurs is likely to be contested. :)
>>
>> Were I to hazard a guess, I would start on the coast somewhere around San
>> Luis Obispo
>
> I think Tod is correct here that north/south is the only split most
> Californians would recognize, and that the dividing line is not consistent.
> (You might also get a "Central California" from some folks, but the
> dividing lines there would be similarly fuzzy.) My wife grew up in San Luis
> Obispo, and people from LA tend to say she's from Northern California and
> San Franciscans say she's from Southern California.

I'm someone who has only been to California occasionally, and for me
also the north/south split is the one that seems the most likely for
many to be able to grasp.

I have never heard of "six californias" in any coherent way; it seemed
new on reading.  And I would have little clue about the edges of those
boundaries even seeing the list of names.  So I think that's not a good
idea, because split extracts need to target being understood by
nonlocals.

I would of course recommend listening to locals about exactly shere
between SF and LA the line is, and I would align to counties so that
each county is in north or south, and have the east-west line more or
less try to follow latitude from the breakpoint from the coast.

With a N/S split like we are converging on, most users that are ok with
half will guess right the first time, and people that care about areas
near the border will get it that they are near the border and need both
or the whole thing.

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

Re: [Talk-us] NYC Name Vandalism

[Greg Troxel]

I tend to agree that automated systems are going to be not that useful.

I tend to notice some things in my area, but it's hard to keep track.

This makes me wonder about a tool that

  - lets people sign up to watch edits, in some area, or in general,
sort of like maproulette.   Use some scoring system where new
mappers edits are more likely to be looked at by somebody, and
people who claim an area as theirs are more likely to get shown
edits there, or maybe let people get all edits in some bbox

  - lets people give a rating to a changeset, something like:
   i) high priority for inspection by others
   ii) worthy of being checked by a local
   iii) probably ok
   iv) definitely ok

  - presents things to multiple people

  - somehow uses a rater's own edit history to validate this (perhaps be
cautious about people with < 500 changesets, and very cautious < 50)


This is a slippery slope to a reputation system, but I think in terms of
culture, the fact that anybody can review is there already, and the
bright line is needing permission to change things, vs a more efficient
way of others looking over changes.


Unfortunately my editor crashed and I lost the source code :-)


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

Re: [Talk-us] Naming numbered roads as "State Route X", "Interstate X", etc.

[Greg Troxel]

  From: Albert Pundt 
  Subject: [Talk-us] Naming numbered roads as "State Route X", "Interstate X", 
etc.
  To: "talk-us@openstreetmap.org Openstreetmap" 
  Date: Fri, 31 Aug 2018 22:06:50 -0400 (10 hours, 17 minutes, 15 seconds ago)
  Attachment: [3. text/html]...

  I notice the user SSR_317 has been adding the route numbers of unnamed
  roads to the name=* tag of roads around Indianapolis. For example,
  name=Interstate
  465, name=US 31, name=State Route 37, etc. Isn't this practice frowned upon
  as being redundant and not reflecting the lack of a proper name to the
  road? This seems to be the case around the country. All route numbers were
  listed in alternate names of the roads in the original TIGER data, but the
  vast majority of these have been removed in favor of route relations and
  ref=* tags.

  I removed these name tags from the affected roads, but the user has since
  re-added them.

Seconded or thirded: a route number is not an actual name and does not
belong in the name tag, or even alt_name.

This has come up (in discussion, not actual edits as far as I know)
because there are some roads in Massachusetts that have actual names and
route numbers (example: name="Grand Army of the Republic Highway"
ref="US 6"), but for reasons unknown there are street addresses like
"3570 Route 6".  Even though there is zero evidence that "Route 6" is is
any way a street name.   As far as I know this is limited to on the
order of a half dozen roads, 1 US highway and about 5 state highways,
mainly in the southeast and cape.

So beyond agreeing that sticking things in name (presumably on the
notion that everything should have a name, even though that notion is
confused as the real world does not have that property), I wanted to
point out that just because a building near a road has an *address* with
a name, doesn't mean that the road itself has that name.




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

Re: [Talk-us] admin_level=8 boundaries in Parker County, TX

[Greg Troxel]

Frederik Ramm  writes:

> I've recently traced a little bit of stuff in Annetta, TX. The area I
> looked at had a lot of potential for someone interested in mapping from
> aerial imagery (houses, tracks, driveways, parking missing; some
> driveways tagged as highway=residential etc.) and I did what I could in
> the small area I worked on, but there was one thing I didn't dare touch
> and that's admin boundaries. The ones I encountered often cut straight
> through residential buildings and I thought that can't be right, but I
> know too little about boundaries in the US to fix any of it. I am
> specifically talking of

Not commenting on that boundary (which others say needs help), but the
logic

  admin-8 bounadry goes through houses
-->
  boundary must be wrong

is incorrect in the US.  Around me, there are multiple houses where the
boundary line indeed goes through them (where I've seen the boundary
markers, seen the houses, and talked to the occupants who pay taxes to
two towns).


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

Re: [Talk-us] Slack: Do we need an Alternative (was Planning an import in Price George...)

[Greg Troxel]

Martijn van Exel  writes:

> Hi Simon,
>
>> > * everyone is on it
>> That's a bit of a self fulfilling prophecy after you've essentially
>> force migrated everybody there and then cut the ties with any other
>> competing media (in OSM) so that you can have your nice walled garden.
>
> I would argue that it is a good thing that people converge on one
> platform to talk about OSM. Whether Slack remains the right choice is
> something we can debate. It was really the only feasible choice that
> was available to us at the time we (OSM US) felt the need for a better
> platform for conversations. Slack has done its job as a for-profit
> non-open company well in the sense that we're somewhat locked in
> now. I dislike the fact that it is a walled garden, and becoming more
> so, as much as anyone who values free and open data and software. If
> there is a practical way to improve that situation, we should pursue
> it.
>
> Finally, please stop your unpleasant trolling, it has no place in OSM.

Slack is a company with terms some don't like.  People should not have
to enter into a contract with some random company to participate in OSM.

I for one am not on the osmf-us slack, and am likely to continue not
being on it.  So "everyone is on it" is demonstrably false.

Another issue is that we are building open data, and open data and open
source go hand in hand philosophically.  So it is not surprising that
members of the OSM community object to proprietary communications
systems.  It is surprising that a non-trivial number of OSM people think
proprietary communication systems are ok.

There is matrix; I haven't tried that, and I've heard positive reports
about self-hosted mattermost.

Another possibility, which might fix the terms issue but not the
proprietary issue, would be for OSMF-US to enter into an agreement with
Slack, Inc. in such a way that OSM people do not have to enter into a
contract, much as if they were employees.

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

Re: [Talk-us] 'address' tags in Massachusetts

[Greg Troxel]

There is a talk-us-massachusetts@ and I think review of your proposed
mechanical edit should include that list.

I suspect people would be amenable, but it would be good to publish the
code, and the proposed files to upload, so that they can be reviewed.
(I'm not clear on the rules for mechanical edits; I'm just asking for
that as a local who is not comfortable with non-trivial mechanical edits
without published code.)

Also, it certainly makes sense that there are some values that are hard
to parse.  The obvious approach is to just leave them out (and leave
them for manual fixing or another day), but I'm not really sure exactly
what you are proposing to do.

As for nodes with both the old addr tag and new ones, you imply that the
simplest way is to clean them up before a mechanical edit.  But that
implies that if they aren't fixed first, you might do something to those
nodes, and that seems against the spirit of the mechanical edit policy,
which involves refraining from changes that you can't basically prove
are correct.  But I don't expect you'd be doing that, so perhaps you can
expand on what you meant.

Greg


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

Re: [Talk-us] Rural US: Correcting Original TIGER Imported Ways

[Greg Troxel]

> For the US, however, you'd want to do something other than just
> "downgrading to track".  There are a couple of options I suspect:

In the US, treating an unpaved road as "track" does not seem right.
Besides the surface issue, there is a very strong notion of legal status
between a "road" (often on its own parcel, traffic laws apply)and a
"track" (just a place where you could drive within some larger lot, and
often considered that traffic laws do not apply).

It also seems to me that the typical rendering of track is heavier and
more visually prominent than highway=residential, where for a
general-use map it seems that tracks are lesser ways.

> One is to split unpaved roads out as a separate "road type" altogether
> (that's how sidewalk and verge are handled as seen at
> https://map.atownsend.org.uk/maps/map/map.html#zoom=15=-24.99273=135.02137
> ).  The other is to have some sort of modifier (like "bridge", but
> different).  that's how "long fords" and embankments at
> https://map.atownsend.org.uk/maps/map/map.html#zoom=15=-24.99958=135.0693
> are handled.

I suspect I'm failing to understand something, but it seems that

  highway=residential surface=paved (or no tag, default)
  highway=residential surface=unpaved

should have rendering that is similar in weight, but with some clue that
one is not paved.  Dashed casing seems plausible.  But I realize this is
very hard as we try to represent more and more in a single map.  I
cannot quibble with your advice to actually try something...




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

Re: [Talk-us] Potential vandalism in Northern California (Pokémon Go?)

[Greg Troxel]

I think the National Park term causes a lot of problems.   As I see it,
there are two kinds of places:

  1) a natural area with some accomodation for human use, which is mostly
  natural except for a few bits.

  2) a semi-natural area which has grass and trees (instead of
  concrete), but is fairly manicured.  In this way it is more like a
  maintained garden than wilderness..

Both of these exist at various scales.

Point 1 is leisure=nature_reserve, more or less.  If there is legal
protection (which is separate from what's there now), it should get
some sort of "landuse=conservation", "boundary=protected_area", or the
special kind of protected_area with an implied leisure=nature_reserve
known as boundary=national_park.

Point 2 is leisure=park.

In New England, in type 1 you are probably going to get ticks, and in
type 2 you probably aren't.

One of the real difficulties is that in areas athat are type 1, such as
a lot of state parks, and national parks, there are significant
sub-areas, often bigger than many town parks, that are very much type 2.

As an example, in Yellowstone, the 6 or so villages where there are
hotels, general stores, maybe a gas station, places with picnic tables,
boardwalks, feel like type 2.   But once you leave those pretty small
areas, you are almost in wilderness.

A "conservation area" in my town might be only 100 acres.  You are in
the forest, with just a cleared trail and blazes.  But at the entrance,
there is a dirt parking lot and a sign with a map.  This is a type 1
area with a very small (enough for 10 cars) part that almost feels a
little type 2 (except the parking lot is barely usable), but it's so
small we just call it type 1.

Whether anybody (administrator of thing or not) uses the work Park is
not relevant at all.


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

Re: [Talk-us] Trunk

[Greg Troxel]

Martijn van Exel  writes:

> In the mean time, I decided to test some of the ideas posted here on a real
> case: The part of Michigan SR 10 northwest of the I-696 interchange:
> https://www.openstreetmap.org/relation/252973#map=13/42.5132/-83.3168
>
> Since 1) this road does not seem to serve an important connecting role in
> the long distance road network 2) the density of abutters and related
> driveway / parking exits I judged a downgrade warranted. Please discuss
> here or on https://www.openstreetmap.org/changeset/52903464 .

If there are enough abutters and driveways (and use of them) that people
driving on the road cannot basically act as if there are none, then it
fails as trunk, so from your description, that sounds good.

I don't think "important connecting role in the long distance road
network" should have anything to do with it.   A regular US highway that
is not divided, grade-separated, mostly limited access is still a key
interconnecting road, and it's squarely "primary".  Most of US 20 is
like this, as I understand it, and all or almost all of the parts I've
driven on (MA, WY) are like that.

> On the topic of tagging for the renderer, two things: 1) A US-specific
> rendering would be really neat 2) Trunk 'appendices' like the one I
> just downgraded do make rendering at low zooms tricky -- you end up
> with short segments that seem to end in nothing.

On point 2: Because the evolved rough consensus is about trunk being
something that would have qualified for primary that also has superior
physical characteristics, there is no reason to expect that displaying
trunk but not primary will result in a connected network or a coherent
map.  Displaying motorway but not trunk will likewise not be connected;
e.g. parts of MA 2 are trunk and part are motorway (and in Boston and
Western MA, merely primary).  The signed route is continuous and part of
the network, but if you start at Alewife you are on motorway (4 lanes
and traffic moves at 80+ mph) and eventually you get to Erving where
it's 1 lane each way, double yellow line, and posted 30, having dropped
to trunk and then had another motorway section.  But it is certainly a long
distance important route, and if you only render 2 EW routes in MA, it's
the second one to show after I-90.

My point then, is that choosing to render trunk but not primary is not
really a thing to do what preserves a sense of networks.  We absolutely
should not thing about how to use motorway/trunk/primary to make maps
rendered that way look good.

People may want to render based on ref tag, or some other "how important
is this route" tag, which could be some combination of how long the road
is and how far away the next road that goes roughly those places but is
faster is.  Others have talked about dropping some Interstate sections
(esp odd 3 digits) at small scales.



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

Re: [Talk-us] Trunk

[Greg Troxel]

Kevin Kenny  writes:

> Perhaps we could reach consensus more easily if we were
> to first try to agree that the goal is to tag both physical character
> and regional importance, and recognize that the two serve
> different needs, and are (in the US) often grossly mismatched?
> Then the discussion could revolve around the question of what
> tagging is for physical character, what tagging is for regional
> significance, and what are objective criteria for assessing
> significance. (It's somewhat subjective, and therefore
> contrary to the OSM spirit of "tag what is visible only on the
> ground", but it's so necessary to getting mapping and routing
> right that I think we have to grasp that particular bull by
> the horns.)

I think that would be a great step forward.

The elephant in the room, though, is that the behavior of the default
render is considered extremely important, and I think a lot of the
debate is at least somewhat tied to controlling how that comes out.


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

Re: [Talk-us] Trunk

[Greg Troxel]

Paul Johnson  writes:

> Would you consider oncoming traffic as conflicting?  That's the crux on the
> super-two debate.  I would consider at least two lanes each way,
> free-flowing, controlled access, and at least two carriageways as the
> minimum threshold for motorways.  Limited access, at-grade intersections,
> single carriageway, this all would be more characteristic of trunks to me.

I don't see it as necessary to define non-divided-highway as conflicting
or not.  In theory, people stay on their side of the yellow line, and it
isn't, but in practice, they cross sometimes.  The point of divided is
of course that they can't cross.  And it leads to needing a 2nd lane for
passing.


I find the notion of super-2 as motorway to be a very minority opinion.
Until Richie supported that position, I would not have expected anyone
to argue that, and I have not seen anyone else take that position.

We do have debates about how far along the primary-motorway continuum a
road has to be in order to be tagged as trunk, and I think that's where
there's a fair bit of fuzz (how many driveways, distance between
intersections, etc. -- e.g., 1/10 miles ok, 10/mile not, and it's hard
somewhere in between).



Does anybody else think that a non-divided highway with one lane in each
direction, even if controlled access, should be tagged motorway rather
than trunk?


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

Re: [Talk-us] Trunk

[Greg Troxel]

Richie Kennedy  writes:

> On Thu, Oct 5, 2017 at 7:48 PM, Paul Johnson  wrote:
>
>> Alternatively, a single
>> carriageway that is limited access, ie, no intersections, no driveways, only
>> ramps (eg, Chickasaw Turnpike in Oklahoma).  Essentially, almost a motorway
>> but not quite there.
>
> I *strongly* dispute Paul's assertion that a highway that has fully
> controlled  access but is single carriageway should be "trunk" instead
> of "motorway." Access control, not number of lanes, should be the
> primary guidance behind a motorway or trunk classification.

I'm with Paul here.  To be motorway, there are three critical
characteristics:

  divided
  >=2 lanes each direction (so passing is possible)
  limited access

If those aren't all true, then it just isn't a motorway.  (I gather
there is a road in Alaska labeled Interstate that doesn't meet all
those, and I don't mind if the locals want to make an exception.  But if
it isn't signed I-, then I don't think there should be exceptions.)



To answer Martijn's question, I also agree with Paul that "trunk" is
something that has a substantial part of the feel of a motorway.  It
might be only one lane in each direction (in NE we do not use the term
super two), it might not be really divided, and it might have occasional
driveways (at most one every quarter mile on average?)  or at-grade
intersections with lights every few miles.

We should realize that the current tags are the result of a long
historical process, including a few mappers that had a minority few that
there should be more higher-classification roads, and did massive
amounts of armchair retagging.


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

Re: [Talk-us] guidelines regarding roads access

[Greg Troxel]

Adam Franco  writes:

> One additional note is that at least in my area, the TIGER import
> incorrectly added access=private to many driveways and privately maintained
> residential roads. Upon surveying these I've found that they are signed
> "Private" or "PVT" on the street-name sign to indicate
> private-maintenance/ownership (don't complain to the town about a lack of
> snow-plowing/grading), but do not in reality have an access restriction.

For a "private way" (legal term in my state for what I think you refer
to as "privately maintained residential road"), I agree that there
shouldn't be access=private.

For a driveway to someone's house, access=private seems right, in that
it's generally at least impolite to use that road other than as
visitor/delivery/etc.

Are you saying that you think access=private on say a 100m driveway from
a real public road to a single house should have no access tag (or
access=yes)?  If so, I don't understand why.

[Veering off into an adjacent topic...]

But, that tends to lead to pink blobs in rendering, and I'm not sure
that's the right thing, as service roads having the status "you should
use these only when dealing with the adjacent entities" seems to be the
default/normal case.  We should adjust rendering, not access, to make
this pleasing.

So I have been putting access=private on driveways for residences and
businesses that don't welcome the public (industrial) as I edit, and not
putting that on servie/driveways for businesses that do welcome the
public (retail and some commercial, more or less).

Part of the issue here is that when thinking about routing, humans know
that osm-ways that are private can be used if they are associated with
your destination (and you have permission/invitation to the
destination).  So perhaps we need some sort of association between ways
and destinations, but that seems like a lot of work, and a lot of bits
in the database, without a clear rationale to a win for routers.


I notice that OSMand has been asking (roughly) "destination is in/near
access=private; ok to use those"?  I'm not sure what I think of this; it
seems that it's normal to use access=private to get someplace if that's
what it takes, since the default assumption of "route me to X" is "it's
ok for me to go to X".  The hard part is if where you want to go isn't
on the same lot, and that private way just happens to be the closest.
This is usually because of a missing driveway for where you are going,
though, so it's reasonable to take the viewpoint that there's a map
error/omission and that the router behavior will be right once that's
fixed.


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

Re: [Talk-us] guidelines regarding roads access

[Greg Troxel]

"Ionut Radu - (p)"  writes:

> For us it's a little bit confusing if we should map those areas with
> service, residential roads or even living streets and if there are
> some gates at the entrance if we should tag them with restrictive
> access.  So, if you know some rules or guidelines regarding those
> particular cases, please give us a feedback.

I would not use living_street unless there really is a legal notion that
matches it.

If there's a gate, and you have to have a code to get through, or if
there is a no trespassing sign, then I would mark it access=private.

It follows from access=yes/permissive that a router can send you there
and it is expected to work.  It follows from access=destination that a
router can send you there if your destination is there and that is
expected to work.  None of that is true with an unmanned code gate.

To find out, take a test drive and see how it goes (not really kidding).

If there's no right of access, but people act as if there is, I would
use access=permissive.


As far as residential vs service (ignoring unclassified/residential), in
Massachusetts I tend to do:

  public way (essentially always named) => residential
  private way  (essentially always named)=> residential

  shared driveway to 3 houses (essentially never named) => service, driveway

The big dividing line is whether the way is laid out as a lot in the
parcels map.  But this is not entirely reliable as there may be named
roads within a condo complex that are not legally separate parcels but
you would have no idea of that from being there.

The other thing is that driveways are usually either too narrow to be
real roads, or very clearly to get you from a main road to a parking lot.

So I would say that roads in gated communities that feel like roads, in
width, usage, and going by many houses, should get highway=residential,
even if not named.

You should also walk around and talk to locals and see what they think
:-)  But most non-mapping locals would think this is an odd question.


Are you armchair mapping, or actually there?


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

Re: [Talk-us] "System Continuity" in the Functional Classification network

[Greg Troxel]

Frederik Ramm  writes:

> Hi,
>
> On 07.09.2017 16:51, Max Erickson wrote:
>> Broadly speaking, yes, such continuity should apply. Maybe not using
>> exactly the same rule as the US DOT.
>
> I know this is talk-us and I won't attempt to say anything USA specific
> but such continuity definitely does not apply world-wide in OSM (there
> have been cases where people tried to enforce such continuity without
> local knowledge only to be repudiated by locals).

I also don't think there is a continuity notion in the US in OSM.

In particular, in the US, we have a notion of primary is a US highway
(or a state highway that is equally important).   So a continuity
property in OSM tagging tends to follow from continuity in the
underlying networks.

trunk, however, is special.  It more or less means "primary which is
50-90% of the way to motorway".  So that means there are stretches where
it changes, and that's ok.  (it shouldn't change every one mile, but 5
miles is defintely normal)



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

Re: [Talk-us] possible upgrade for residential roads in Detroit

[Greg Troxel]

"Ionut Radu - (p)"  writes:

> I was looking over residential roads in central area of Detroit and I
> was wondering if some of them should be upgraded to a superior
> function class (e.g. tertiary or secondary).
> Lots of them are Avenues and Boulevards with at least two lanes and seems to 
> be major collector roads.
> I think they were imported from TIGER Roads and some of them need a review 
> check.

Secondary typically is "state highway, or road that is important as a
state highway".  That will be fairly rare.

In rural areas, tertiary is typically a road that gets you to another
town, or to a different local area even if not across a boundary.  So
the roads people use to travel to a place that's in a different 1
people population center should be tertiary.  That's too broad brush and
not really right, but I suggest that following it leads to sane results.


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

Re: [Talk-us] Differences with USA admin_level tagging

[Greg Troxel]

Kevin Kenny  writes:

> So to me, what makes sense for New York:
>
> admin level 2 - United States of America
> admin level 4 - New York State
> admin level 5 - New York City, special case
> admin level 6 - County, Borough (within New York City)
> admin level 7 - Town, City
> admin level 8 - Vlllage, hamlet (where borders defined), community
> district (New York City), City of Sherrill

It seems from reading your comments cities are within towns, that a
house within a city is also within a town.  So I do not follow putting
them at the same level.  But it also seems that legally the notion that
a house in a city is within the town has no consequence, in terms of not
having to follow town law (perhaps there are no town laws) and not
having to pay town taxes.  So I think you are saying that effectively
being in a city means you aren't within a town, even though you are
within the polygon.  Is that a fair read?

The other question I have about your list is about town/city being at 7
vs 8.  It seems that in most states, the city type of thing is at 8.
The numbers are arbitrary, just leaving room for some 7 thing that might
or might not exist.  But it seems good in terms of data consumers for
~everything that's sort of like a city (to include Mass towns) to be at
8, to reduce the need for special-case code.  That would put
village/hamlet at 9, which strikes me as also aligned.

This raises the notion if there are places in the US where there is
something smaller than a county and bigger than a city in a meaningful
way, for example a state where cities are in townships but city
residents also have town law/tax consequences, which would lead to
town=7 city=8.

> This scheme differs from what I see on the Wiki only in that the
> sixty-odd cities other than New York and Sherrill would be promoted
> from level 8 to level 7.

Which I guess is exactly my question, more succinctly :-)


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

Re: [Talk-us] Differences with USA admin_level tagging

[Greg Troxel]

Greg Troxel <g...@lexort.com> writes:

> In many new england states you list Town as 7 and City as 8.  As a
> local, this makes no sense to me.

I misspoke about "you", sorry.  Let me try again:

At
  https://wiki.openstreetmap.org/wiki/United_States_admin_level

it says that in Massachusetts,

  Town should be tagged as 7, and City as 8.

This is just plain wrong, and I don't know where it came from.  I think
it's based on the notion that there is a thing "Township" between county
and city.  The text above on the page says:

   found in all of the northeastern states known as New England and most
   Midwestern states is a government between county and city called
   "township,"

and this is clearly incorrect for Massachusetts.  The word "township" is
not used at all in our state, and "towns" are peers of "cities", equal
in all respects except for minor form of government differences, and
they do not overlap.  I also think it's incorrect for at least most
other New England states, but I am not certain.

I see someone (you?) has aligned the table with dobratzp's suggestions.
That's great progress.

I fixed the incorrect statement about townships, narrowing to CT, on the
theory that it's far better to omit a fact which might be true than to
have an incorrect statement.


Also, the text says:

  while in New England, governments tend toward weak-county /
  strong-city, to where in at least one state, "county" vanishes
  entirely.

This may be sort of true, but I think it should be dropped.

Reading the discussion page, Dobratzp's revision to the table seems
right to me (except that I don't understand CT so will refrain from
commenting on it)..  As a nit, I think precincts within towns should be
10, to match city, not 9.  A town basically has 1 ward, which shouldn't
promote precinct.  (Plus, I'm not sure we should map wards and precincts
anyway.)


And thanks for digging into fixing this.  It is interesting but not
shocking that we are finding that the locals curating the data are right
and the wiki is not.


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

Re: [Talk-us] Differences with USA admin_level tagging

[Greg Troxel]

Kevin Kenny  writes:

> The default municipality elsewhere is a town. This is what you get
> when you don't incorporate. Towns do not cross county lines. They are
> similar to townships in other states. Every resident in New York State
> resides in a town, a city, or on a Native American reservation.
>
> Incorporated communities include cities and villages. None of these
> cross county lines, except for the sui generis City of New York, and
> the City of Geneva, which is primarily in Ontario County but has
> annexed some land in the adjoining Seneca County.
>
> Cities are independent from the towns that spatially contain them.
> They operate entirely independently of the town, and generally have
> their own charters (constitutions). (Exception: The city of Sherrill
> has surrendered most of its independence and is treated as a village
> in the Town of Vernon.)
>
> Villages have more limited home rule. A handful are chartered, while
> most are governed by a uniform statewide Village Law. About 85% of
> them fall within a single town, while the remaining 15% are divided
> among two or more towns, which may or may not be in the same county.
> In all cases, the residents of a village are residents both of the
> village and of some town, and owe taxes to both.
>
> Below towns are also encountered hamlets. These have no independent
> existence or home rule at all. Their borders in some towns are fluid,
> with a cluster of houses or neighborhood being identified by a name.
> In other towns, the hamlets are coincident with planning districts or
> have special zoning, and are signed at their borders. Certainly, the
> towns that promulgate zoning regulations, parking regulations,
> planning policies, and so on by named hamlet deserve to have their
> hamlets' borders marked on the map, even if the hamlets have no home
> rule.

No objections to your comments on New York; I don't know the rules at
all.  I will just point out that this is totally different from
Massachusetts, where cities are not within towns, and 99% villages and
hamlets are place names not administrative divisions.  (A few larger
cities do have named subregions that have some but not much political
significance.  I don't think any of them have separate laws or separate
taxes.)


A key point is that OSM has words Town and City and these have
OSM-defined meanings, and each state may well use those same words to
mean different things, and we have to  be careful to separate local
language and OSM language.

For instance, OSM seems to use city, town, village, and hamlet as
members of a settlment hierarchy of populated places with varying
populations.  That's fine as a general notion in human geography, but I
see it as totally separate from admin tagging.  I don't think we are
having that confusion, but wanted to point this out in case.


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

Re: [Talk-us] Differences with USA admin_level tagging

[Greg Troxel]

In many new england states you list Town as 7 and City as 8.  As a
local, this makes no sense to me.   We have to keep separate what OSM
means by words and what various places mean; often they are different.
It's when they are close but not quite that it's extra hard!



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

Re: [Talk-us] Differences with USA admin_level tagging

[Greg Troxel]

OSM Volunteer stevea  writes:

> To read this, then perhaps participate in first discussion, then
> possibly "solve" these issues, take the second line (Massachusetts) as
> an example.  Massachusetts did the MassGIS import, which included
> "City" boundaries and set their admin_level values to 8.

Actually, the current boundary data comes from a second import of
massgis data separate from the original imports.  And I have personally
verified muliple data points from this import, traipsing through the
woods with a GPS receiver and checking highly verifiable painted granite
markers vs the data, and can tell you (and Frederik :-) that it is
excellent-quality data.

> However, I assert (politely) that Massachusetts also has "Town"
> boundaries (sometimes called "Township" and by consensus yielding an
> admin_level value of 7) which either are or aren't in OSM (I can't
> tell) and which should have their admin_level set to 7.  But it
> appears they do not.  Again, OSM seems to need to identify "which,
> whether and how" we do this, on a state-by-state basis, in
> identifiably (only) nine US states.  I have taken it about as far as I
> can go, Minh has does yeoman work, we now have a "diff list" and now I
> post to talk-us to help us better untangle.  Can YOU "take a state or
> two" and help?

The notion that Town and City are fundamentally different in
Massachusetts is incorrect.   I think that's the long and short of your
basis for commenting, but if I'm off please tell me.

Massachusetts towns are never called townships.  That might be the case
in other states, but it feels to me more midatlantic (or at least new
yorky) than new englandy.  I have never heard them referred to by this
word.  Perhaps in maine, related to something that feels like public
land survey system way up north.

From a state government point of view, the state is divided into
municipalities., where every bit of land in the state is in exactly one
municipal entity.  Whether a particular entity is Town vs City is merely
a detail of the form of government, in terms of Board of Selectman and
Town Meeting vs Mayor and City Council (more or less; there are multiple
kinds of cities and that's messy, but they all I think have councils).
Both have zoning bylaws, general bylaws, property tax, police chief,
school committees, planning boards, conservation commissions, and
various other things all the same.  The town meeting vs city council is
really a minor distinction.  Sometimes a town changes into a city; I
think Framingham just did or is about to.  Other than people who live
there and elections, it's almost unremarkable except for rarity.

In particular, cities are not contained within towns.  They are peers,
fully equal in all ways, with a minor difference in government
organization.  Nobody I know thinks one is at a higher level than the
other.

So I really do not understand the notion that there is anything wrong.
As a resident of a Massachusetts town, and as the person responsible to
the Board of Selectman to verify the boundary markers :-), I think the
current admin_level=8 equal treatment for Massachusetts cities and towns
is correct.

(I realize that in the human geography hierarchy of populated places,
there is a notion that cities are bigger than towns.  While that's often
true in Massachusetts (Boston is bigger than Florida), it's not part of
the definition.)

Not trying to give you a hard time, but I'm a local and I"m into this
:-)


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

[Talk-us] Boston Globe Marathon map has OSM basemap!

[Greg Troxel]

And it's even attributed.  (I did write to someone at the Globe long ago
about a prior unattributed map.)

Beware that the page is really infested with ads/trackers.  Install
uMatrix before visiting :-)

https://www.boston.com/sports/boston-marathon/2016/04/15/boston-marathon-course-route-map-2016


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

Re: [Talk-us] Dakota County, MN Building Import

[Greg Troxel]

 writes:

> On that page, it states Dakota County encourages public use of this
> GIS data.  “The County Board of Commissioners adopted a policy of free
> and open GIS data, in collaboration with the other six metropolitan
> counties in the Twin Cities.  More information on this initiative is
> available from MetroGIS. “ The page that in links to is the hub for
> all this licensing stuff.  In the documents it defines Open as “no
> legal agreements or other conditional encumbrances required to access
> the data” and “no constrain on the use of the data once acquired by
> the user”.
>
> Do they have to explicitly say CT/ODbl on the website or does it
> suffice they link to the policy created by all counties in the metro
> that says, free take it, no contraints?

There is no need to refer to CT/ODbL.  What's necessary is clear
permission to use the data under terms that are acceptable.  (I'm just a
random member of the imports list, and if the consensus is that this
license is good enough, I won't object.)

I think we are talking about:

   https://www.co.dakota.mn.us/HomeProperty/MappingServices/GISData

and the text at the bottom includes

  If you transmit or provide the GIS Data (or any portion of it) to
  another user, you must provide a copy of this disclaimer and the
  accompanying metadata for this dataset to the user.

This qualifies as open data; it's logically similar to attribution
requirements in various software licenses, and those are not
disqualified from being Free (FSF) or Open Source (OSI).  But software
is generally a bunch of files, and carrying such license text is
trivial.  In the OSM case, there's a large vector database with no
facility for disclaimers (except on the web site), and data is routinely
extracted.  OSM doesn't want to impose these notice requirements on
users of the database.

It may be that adding this disclaimer to the set at

  https://www.openstreetmap.org/copyright

is sufficient.  But OSM cannot provide copies of a county's disclaimer
to all people who access OSM data that might include some of that data.

Going to the metrogis site, and finding the Dakota County resolution, I
see that it says:

  NOW, THEREFORE, BE IT RESOLVED, That the Dakota County Board of
  Commissioners hereby authorizes the Office of GIS to publish its public
  geospatial data on its website in a commonly recognized and easily
  produced form, available for download by anyone at no cost, subject to
  accepting the terms of the data disclaimer GIS data usage agreement; and

and the "data disclaimer GIS usage agreement".   So the metrogis Free
and Open notion is not really the issue; it's the requirement to provide
a copy of the disclaimer and metadata.

OSM's usage is of course within the broad spirit of this; the metadata
should be in the chagngeset comments, and that's accessible to those who
want to look it up.

For what it's worth, in Massachusetts the terms are generally "public
domain, with attribution requested", which has been ok.


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

Re: [Talk-us] Dakota County, MN Building Import

[Greg Troxel]

 writes:

> Free and Open.  Dakota County encourages the use of its published data
> and supports it being added to OSM.  They are aware of the project and
> do not object.

That's great to hear.  Can you ask them to update their website to make
permission to copy and incorporate clear, without any additional
requirements, so that it's compatible with the CT/ODbL?

The terms quoted by Rory and incompatible with OSM.


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

Re: [Talk-us] Blue Ridge Parkway

[Greg Troxel]

To me the biggest point is that having a tag "boundary=national_park" in
OSM that is somehow tied to exactly which flavor of park administered by
exactly which government *in the US* seems broken.  The general OSM
model is to have tags that have some meaning that can reasonably be
applied everywhere.

So if we define "national park" to be

  an area of land that is
- managed by a fairly large-sized element of government with
  authority to make law
- managed to preserve the land (and sometimes contents) indefinitely
  into the future, and intended to provide access to that land for
  visitors 
- considered within the country it is in to be of high significance,
  (perhaps on the order of 1 park per million people, but really
  that's not right)

then things are probably fine.  This does not leave room for saying that
of the ~500 entities managed by the US National Park Service, only ~50
use the wordds "National Park".  Other countries surely do not use the
same (arbitrary) distinctions among National Park, National Historic
Park, National Seashore, National Monument, etc.  I would fully expect
each country to have a slightly different (arbritary) set of naming
rules.

Around me (amusingly as we discuss British influence on tagging) is
"Minuteman National Historic Park".  This is not a "National Park", but
it has the same kind rangers in the same uniforms, the same kinds of
rules, and is managed to preserve the historic landscape of the start of
the American Revolution for future generations while providing access to
visit it.  It is hugely significant in the US; just not as big as
Yellowstone.  (It's not just a "works of humans vs works of nature"
distinction; Mesa Verde National Park, unarguably a 1st-class "National
Park" is preserving cliff dwellings from ~1000 years ago.)

So I think it's fine to tag all the NPS units as
boundary=national_park.  Perhaps we should have some national-specific
subtagging, like

national_park:us=(national_park|national_historic_park|national_monument|)

and then data consumers that care can make fine distinctions, and people
can avoid worrying about where the edge is.

In many ways this is much like highway=primary/secondary.

As Kevin points out, the real problem is rendering support for a
reasonable tagging mode, and I think we should be totally ok with
good-faith close-enough-for-now tagging until that's fixed.

Part of the rendering problem is that "landuse=consersation", used in
Massachusetts, was deprecated and not rendered, rather than being
promoted.  Every bit of land (at the level parcel or similarly large
chunk or groups of similar parcels) should have exactly one landuse tag,
and eventually there should also be a (different) tiling with exactly
one landcover tag.  Generally for these "national park"-like entities we
are discussing, landuse=conservation is appropriate.  A city park,
however, perhaps should be more like landuse=leisure, but that can be a
tough call (which I suggest should not matter much in edge cases).


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

Re: [Talk-us] Choptank River

[Greg Troxel]

Simon Poole  writes:

> Am 16.01.2017 um 15:08 schrieb Christoph Hormann:
>
>> On Sunday 15 January 2017, Simon Poole wrote:
>>> Given that Washington is supposedly the global centre of mapping
>>> goodness, I hope we might be able to find somebody there that perhaps
>>> is interested in fixing the, I must say with 120km really far away,
>>> area a bit.
>> Note the phenomenon that we have well mapped urban centres immediately 
>> next to extremely poorly mapped areas is something not specific to the 
>> US at all.
>>
>> My favorite example for this is usually Singapore where you can find 
>> some extremely badly mapped areas less than 50km to the south:
> I wasn't aware that there were organisations in Singapore that are are
> suggesting mapping everywhere except on your own doorstep, but thanks
> for clarifying that.

I feel like I am missing some humor and don't follow these comments.
Around me, 120 km really is pretty far away, and the notion that cities
have a few active mappers and areas with small populations do not is not
surprising.



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

Re: [Talk-us] Boston speed limit too Re: Michigan speed limit changes coming soon

[Greg Troxel]

Bill Ricker  writes:

> ​the question then is, can we tell (without driving in circles) is if an
> existing ​30 mph tag in Boston was implicit or explicit ... to find which
> might need fixing

No, you probably can't.  Perhaps massdot will update and you can
compare.  But, I see almost zero speed limit signs refllecting the 30mph
thickly-settled limit.  I see very few for the unposted 40 (notb thickly
settled, not divided), and pretty much every divided highway (50 if not
posted) is posted one way or the other.

But this also seems like  distinction without a difference, and I don't
think anybody is going to slow down...


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

Re: [Talk-us] Boston speed limit too Re: Michigan speed limit changes coming soon

[Greg Troxel]

Also, we do have the implicit 30 mph tagged on many roads.   While there
are usually not signs, it is entirely verifable.  One only has to read
the law and measure the distance between houses (or observe that the
area is built up with businesses).   These two tasks are entirely within
the ability of a typical mapper.



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

Re: [Talk-us] Bar vs Pub vs Restaurant in the US?

[Greg Troxel]

Andrew Wiseman  writes:

> On Thursday, September 29, 2016, Jeffrey Ollie  wrote:
>
>> I think that you're all overthinking it, and trying to fit a European
>> square into a US circle. First of all, the US doesn't have pubs, unless the
>> owner is specifically trying to recreate the atmosphere of a European pub
>> (or at least what an Americans think a European pub is). Doesn't matter if
>> a European visiting the US would think of the establishment as such, they
>> just don't really exist around here.
>
> If that's the case then the majority of places we call bars in the US
> should actually be tagged as "restaurant", no? Because a "bar" in OSM is a
> place without food. But I don't think that's right.

Part of the problem is that the original definitions of tags were
exactly the UK definitions, instead of them being extended to make sense
globally.  So I think things like amenity=bar have to bend a little to
cover places that are mainly focused on drinking other than beer, but
might have some food.  This preserves the spirit of the original
meaning, but expands it to things that are conceptually the same but
don't meet the strict definition.





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

Re: [Talk-us] Bar vs Pub vs Restaurant in the US?

[Greg Troxel]

Harald Kliems <kli...@gmail.com> writes:

> On Thu, Sep 29, 2016 at 12:17 PM Greg Troxel <g...@lexort.com> wrote:
>
>>
>> That's not what the OSM tag means; it's more european.  In OSM, "cafe"
>> means (usually) that there is real food, but (always) that you order at
>> a counter and then either take it yourself or have the staff bring it to
>> you.  However, a coffee shop is very probably a cafe under this
>> definition.  But so is a place that has real food cooked by a chef,
>> except that you don't get waited on.

> Where do you get the order-at-the-counter vs table service part from? I
> don't see that in the wiki, and the picture on the amenity=cafe page shows
> a waiter in an Austrian cafe, who most likely will take your order at the
> table. https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dcafe Furthermore,
> there is a separate tag for self service
> https://wiki.openstreetmap.org/wiki/Key:self_service

I really do not remember clearly where I read this; it would have been
about 5 years ago.


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

Re: [Talk-us] Bar vs Pub vs Restaurant in the US?

[Greg Troxel]

Jeffrey Ollie  writes:

> Third, the laws/regulations around liquor licenses are complex for various
> historical and political reasons and vary state by state and probably even
> city by city. What classifies as a bar in one state might be a restaurant
> in another.

Agreed that terms in local law should be ignored.

> So, trying to come up with hard and fast rules as to what's a pub, bar or
> restaurant is doomed to failure. The only test that makes any sense is
> "what do the locals consider it?" I know that's too fuzzy for some people
> but trying to come up with precise definitions for OSM is doomed to failure
> because there aren't precise definitions in the real world.

I agree with the "what does it feel like" part, but not "what the locals
call it".  One of the central issues in tagging in OSM is that words are
used for a specific meaning (usually UK usage, as we know) and the point
is to have a consistent labeling of things around the world, even if
local language is different.  So that leads to "what would someone from
the UK, but who had lived in the area for a year, call it?".

But, I completely agree that the boundaries are fuzzy and that it does
not really matter which is used when it's close.


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

Re: [Talk-us] Bar vs Pub vs Restaurant in the US?

[Greg Troxel]

Andrew Wiseman  writes:

> The wiki uses a European context, so here's my attempt at classifying what
> is what in the US. Let me know what you think.

I mostly agree; comments on details.

> To me, a "pub" in the US would be bars that have food, but the food isn't
> the main attraction - you mainly go there to hang out or talk with friends
> or watch the game or just drink, but they may have food too. For example, a
> sports bar or your neighborhood bar if they have wings or nachos or
> burgers, but that's not the main draw. Wonderland in DC, for a specific
> example.

pub/restaurant is hard, as both have food.  But agreed that if (some
combination of) the primary draw is a great beer selection, the ambience
is "in a bar" vs "restaurant that has a bar someplace", and if the menu
tends to burgers and pizza, then pub is the right call.

> A "bar" would be a place that doesn't serve food at all, like a cocktail
> bar or just some bar without food, where they might not have seats, which
> is something the wiki suggests. The Adams Morgan area in Washington, DC has
> a lot of these places, for example, where people stand around and drink
> mostly, maybe dance too. McSorley's in New York would be another example of
> a bar, with seats.

Or even places that have some food, but are not really intending to have
meals.   Or where the food is really really secondary as you say.

> And a "restaurant" would be a place where there is alcohol but you mainly
> go for food -- for example, bar and grill chains TGI Fridays, Applebee's,
> Buffalo Wild Wings, etc. would fall into this category. So would non-chains
> that are similar. I would posit that most people don't go to TGI Friday's
> just to drink.

Yes, but restaurant in OSM also requires that you are seated at tables
with table service.  if you get it yourself, then:

> There's also "cafe" as a separate tag which can include food and alcohol,
> but to me a cafe is a coffee shop that might also have beer or food, but
> coffee is the main attraction -- like a Starbucks in the US.

That's not what the OSM tag means; it's more european.  In OSM, "cafe"
means (usually) that there is real food, but (always) that you order at
a counter and then either take it yourself or have the staff bring it to
you.  However, a coffee shop is very probably a cafe under this
definition.  But so is a place that has real food cooked by a chef,
except that you don't get waited on.

One area of disagreement you'll find is the boundary between fastfood
and cafe.  A McDonald's, to pick the poster child, is clearly "fast
food".  The OSM definition talks about how the food is prepared in
advance vs to order for a specific customer.  I have been tagging dunkin
donuts as fast food rather than cafe; you can get a sausage egg and
cheese - but it's factory food in the microwave.  Starbucks I see as on
the line, and boutique coffee shops tend to get cafe.  This is
troublesome because it more or less comes down to "real food" vs
"factory food".


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

Re: [Talk-us] MassGIS Road Import - Lanes

[Greg Troxel]

Bill Ricker  writes:

> On Fri, Sep 23, 2016 at 2:27 PM, Spencer Gardner
>  wrote:
>> Is anyone on here familiar with the process that was used to upload MassGIS
>> road data for the state of Massachusetts? I'm noticing a lot of incorrect
>> lane information on one-way residential streets and wondering if the bulk
>> import process could be the cause. I'd love to hear if anyone else has come
>> across this.
>
> Not intimately knowledgeable here, but aware. I recall there was
> widespread problem with one-way streets because the import was
> inconsistent in one-way polarity. Those are i hope mostly fixed by
> now. I don't recall discussion of lanes, though.

A nit: asq I understand it, the road data is maintained by MassDOT
(formerly > EOT, Executive Office of Transportation), and made available
by MassGIS:
  
http://www.mass.gov/anf/research-and-tech/it-serv-and-support/application-serv/office-of-geographic-information-massgis/datalayers/eotroads.html

The one-way issue was due to a belief at the time that the EOT/MassGIS
dataset had information about whether a road was oneway but not the
direction, because the direction was somehow proprietary data from some
external provider.  As a result the one-way roads had a FIXME and have
largely been corrected.

> My own street is similar, one-way and we have 1 travel lane plus both
> side parking in reality and it's coded as lanes = 2.

I am unclear on lanes.  It would help to analyze a significant number
(10-25?) of roads, comparing what's in OSM to reality and also what's in
the latest state data.  There could be differences in definition of
what's a travel lane vs parking between OSM and MassDOT.
  https://wiki.openstreetmap.org/wiki/Key:lanes

Definitely at the time, and arguably still, the EOT/MassGIS road data
was vastly better than TIGER.  The geometry is excellent, and road
naming is very accurate -- I've only found one or two errors.

If there is some pervasive issue with lanes, a mechanical edit could
make sense.  But I would like to tread carefully there.

I've added talk-us-massachusetts which is probably more appropriate for
the details.


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

Re: [Talk-us] Deleting / Closing / Renaming all places in a chain

[Greg Troxel]

Frederik Ramm  writes:

> Hi,
>
> On 09/07/2016 02:48 AM, Mike N wrote:
>> But if one less 
>> thing is wrong or outdated, that makes the data more useful to all clients.
>
> Except those humans who could have used that outdated thing as a marker
> to tell them that the map is dated.
>
> Yes they could look at the last modification date of things or analyze
> how many contributors the area has or myriad other OSM insider things.
> But seeing a "Domino's Pizza" on the map doesn't need an API, or insider
> knowledge, it doesn't even need a web site - it is the universal
> language of map dating.
>
> Automatically fixing that is like a car salesperson fixing a leak with
> bubble gum because it looks better and they can't be bothered to fix it
> properly.

Your comment comes across as bizarre and hostile to the US mapping
community, as if you think it's horribly broken and proving that point
is more important than improving the map.


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

Re: [Talk-us] [Imports] Kansas City addresses from maps.kcmo.org

[Greg Troxel]

Clifford Snow  writes:

> On Thu, Jul 28, 2016 at 12:02 PM, teslas_moustache <
> teslas_mousta...@riseup.net> wrote:
>
>> I'm not sure if property lines and ownership are useful. And I don't
>> think that building outlines are included, so I may need to continue
>> with drawing rectangles for a while. But hey, addresses!
>
> While property lines don't belong in OSM, they can be useful. Having parcel
> boundaries can be useful to figure out the address of a building.
> Especially if you can get access to the property, i.e. the owner has no
> trespassing signs posted. Other tools such as QGIS and PostGIS come in
> handy for getting your data ready for import.

Two non-import thoughts:

  In Mass we have a tiled raster datalayer rendered from the vector
  parcels database.  This is transparent with white lines for lot lines
  and address/parcel.  It's highly useful for figuring out addresses and
  also adjusting geometry of open space, parks, etc. when making landuse
  polygons.  Code (by Jason Remillard, not me) is at:
  https://github.com/jremillard/osm_massgis_tiles

  Even though the current mostly consensus is that property lines don't
  belong in OSM, they are really useful in making maps.  So if you can
  produce and host an osm-format file with property lines (I use
  boundary=parcel as the tag in my private files), then people can merge
  them with the OSM data to produce e.g. a garmin-format map or a map
  for OSMand, or their own mapnik render.   Perhaps OSMF-US has
  resources to host these files.


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

Re: [Talk-us] [Imports] Status and progress: NYS DEC Lands reimport

[Greg Troxel]

Martin Koppenhoefer  writes:

> On this particular issue I believe you should use different tagging.
> Currently there is almost no use of access=permit
> http://taginfo.openstreetmap.org/tags/access=permit
> Typically if you require a permission for access it is "private" (maybe
> something with "access:conditional" would also be appropriate:
> http://taginfo.openstreetmap.org/keys/access%3Aconditional#values ), you
> could still link the detailed specifiication with a similar tag, like
> access:website=http://www.dec.ny.gov/outdoor/7815.html
> (choosing from the most frequently used tags, maybe it could be
> "source:access"?)

It seems like the tagging schema should be improved.  As I see it
there's a big difference between

  private, and really there is no expectation that some random person
  can easily/reasonably get permission or that it's reasonable to ask

  a permit system, where it's controlled somehow, but really you can go
  there after you follow the rules, and there's an expectation that
  permits will be issued to those who ask

The second case also sort of applies to backcountry in national parks,
except technically you only need a permit for camping overnight.


Perhaps you are saying that access=conditional has some established
semantics that would capture this.


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

Re: [Talk-us] Common names of highways do not match road signs.

[Greg Troxel]

Paul Johnson  writes:

> On Thu, Jul 7, 2016 at 9:32 PM, Kevin Morgan 
> wrote:
>
>> It is confusing to use open street maps in my area(Central Ohio) for
>> driving directions since the "common names" of high ways do not match
>> road signs. The common names are used by open map chest for road names.
>> For example when turning on to State Route 315 with OpenMapChest loaded
>> on my GPS I am directed to turn on to Olentangy Freeway. However the
>> tiger name on open street maps is State route 315. Would it make more
>> sense to configure driving maps to use tiger names for driving
>> directions,  change commons names to include the state route number or
>> interstate number, or add state route number/ interstate number as a
>> different tag?
>>
>
> ref=* isn't name=*, don't tag for the renderer.  I'd go with the official
> name for name=*.  If you're inclined to do something like, name=State Route
> 315, you really want ref=OH 315.   Not all highways with refs will have
> names, not all highways with names have refs.  In particularly remote
> areas, it's not uncommon for a road to not have a name or a ref.
> Conversely, there's highways that might have eight or nine refs and
> multiple names.

I agree.   Around me, there are roads that have both a name and a ref.
Some of them are locally called by one, and some by the other, and there
is no real pattern.

When converting to garmin format with mkgmap, and I think with osmand, I
will tend to hear both the name and the ref.  That's a big lengthy, but
there's no real pattern on which to leave out.  Except perhaps if there
is a new tag that says whether locals call it by name or ref.  I made
garmin osm data for someone to upgrade them from old proprietary data,
and they commented out the dual name/ref was really helpful compared to
how the proprietary data only had one.

So I think Kevin should look at the mkgmap rules and end up with a name
in garmin format that is basically name+ref.  Or he can make it be just
ref, if that works for him.

But definitely don't adjust the OSM database for this.


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

Re: [Talk-us] NYC DEC Lands reimport

[Greg Troxel]

Kevin Kenny  writes:

> I used leisure=nature_reserve and boundary=protected_area
> protect_class=1b for these six areas. The appearance therefore
> changes. If you want it to change back, convince me that there's a
> consensus that landuse=forest would not be tagging for the renderer.

I think you did it exactly right.   They should be tagged
landuse=conservation and renderers should have some green tint, and good
luck with that


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

Re: [Talk-us] Proposed import cleanup: NYSDEClands

[Greg Troxel]

Kevin Kenny  writes:

> landuse=conservation is formally deprecated.

This is the real bug.  There should be a set of landuse= tags that are
jointly exhaustive and mutually exclusive and this one is obviously
missing.  It describes exactly what you are trying to express.

> I fall back on leisure=nature_reserve unless someone screams.

That sounds fine to me; as long as humans are permitted, it isn't wrong.

However, I'd encourage you to put landuse=conservation if not other
documented landuse= tag plausibly fits.  If enough people use it, we can
reopen the formal discussion.


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

Re: [Talk-us] Best practices for dealing with old TIGER tags?

[Greg Troxel]

Eric Ladner <eric.lad...@gmail.com> writes:

> On Sat, Jun 4, 2016 at 5:58 AM Greg Troxel <g...@ir.bbn.com> wrote:
>
>>
>> Kevin Kenny <kevin.b.kenny+...@gmail.com> writes:
>>
>> > OK, 'residential' if it looks like 'subdivision', 'unclassified'
>> > otherwise (as long as it's drivable in, say, my daughter's car rather
>> > than my 4-wheeler). Got it.
>>
>> I also see a distinction between residential/unclassified as denoting a
>> legal road (around me, carved-out parcel wise from the surrounding land)
>> vs track and some service denoting a non-legal-road.  However, others
>> see the physical and legal attributes as separate.
>>
> My understanding of the description of "unclassified" is unclassified is a
> step between residential and tertiary.   It's a connecting road, minor
> connector, whatever, that doesn't have residential on it, but it's not high
> enough in classification to make it a tertiary road.

I agree with that notion.

> I usually use it for roads in industrial complexes, loops around malls,
> business complexes, or other connectors/roads where there's no obvious
> residential around.

Mostly agree, but I only use it for legal roads, not driveways or
private roads.  Meaning someplace where (in new england) it's legally
separate and the public has a right of access.


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

Re: [Talk-us] Best practices for dealing with old TIGER tags?

[Greg Troxel]

Kevin Kenny  writes:

> OK, 'residential' if it looks like 'subdivision', 'unclassified'
> otherwise (as long as it's drivable in, say, my daughter's car rather
> than my 4-wheeler). Got it.

I also see a distinction between residential/unclassified as denoting a
legal road (around me, carved-out parcel wise from the surrounding land)
vs track and some service denoting a non-legal-road.  However, others
see the physical and legal attributes as separate.

If you do change a legal road to track because of poor condition, please
add access=yes if that is how it is.  highway=residential has a pretty
safe access=yes default, and I find that most highway=track are not
actually access=yes, even though most do not have tags.  This is further
messy on rendering, as it might be that tracks should be rendered with
an access color if they are access=yes, and not colored if they are
access=private.

> I suspect that 'residential'/'unclassified' right now is almost a
> difference without a distinction.

In the US, that's true.  Driving in Scotland recently gave me more
insight into the UK origins of the classification.

> I suppose that 'residential' might be a weak indication to a router to
> avoid the route, but the consequences of getting it wrong don't appear
> to be terribly severe.  Which is a relief.

I would say that a router avoiding residential is incorrect, unless it's
a tiny bit of avoidance.   It should really be about speeds, width,
lights, etc.

As for where Richard Welty draws the line, if there are a lot of houses
on 4 acre lots, I don't think that's iffy.  The questions to me is not
subdivision but

  whether most of the landuse along the road is residential or not

and the much harder

  whether much of the traffic is to/from residential vs other, which is
  even harder for collector roads to neighborhoods and what you call
  through

in the end I tink where this line is drawn is very far down on the OSM
problem list.


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

Re: [Talk-us] How are US county boundaries legally defined?

[Greg Troxel]

Jake  writes:

> US mappers - do any of you know what government body is the keeper of truth
> for Missouri county boundaries?

I don't, but I would call the state GIS or highway departments and ask.
It is likely that the country boundaries are defined in state statute
and that it is readily available once you find the magic words to locate
it.  The 2nd link below has a shapefile  (license unclear to me).


http://oa.mo.gov/information-technology-itsd/it-governance/office-geospatial-information
https://data.mo.gov/Demographics/Missouri-County-Boundaries-Map/n34b-fwqr

http://msdis.missouri.edu/

http://extension.missouri.edu/p/G810


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

Re: [Talk-us] Timezones in USA?

[Greg Troxel]

Frederik Ramm  writes:

> I have deleted a couple of such time zone polygons account of not being
> verifiable on the ground.
>
> I don't know how time zones are defined "at the source" but it is very
> unlikely that someone puts up signs. I guess there'll be some kind of
> definition that can be kept *outside* of OSM, and can be translated to
> polygons with the help of OSM if desired.

This strict on-the-ground notion is overblown.  The real issue in
verifiability is if an ordinary mapper can check the data.  Everyone
around me knows that timezone they are in.  I'm sure everyone near a
boundary knows where it is.  The rules are easily accessible in
libraries, and they refer to boundaries that are signed (in the US,
usually state lines).  You can look at clocks displayed in public.

The real issue is where to draw the line about specialized details that
don't belong on map.  In the case of time zones, they are something that
has traditionally been represented on maps for a long time, in a base
map kind of way, vs a thematic data shown on a base map kind of way.


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

Re: [Talk-us] Optimal / preferred checkin sizes

[Greg Troxel]

"Steve Friedl"  writes:

> I don't think that 3 square miles of road straightening ought to go in a
> single [enormous] batch, but I'm not sure that 100 entries of the form
> 'Straightened Main Street in MyTown" / "Straightened Elm Street in MyTown" /
> "Straightened Euclid Steet in MyTown" is really adding any value.
>
> How does one decide how best to check stuff in?

I think it's much like software: a group of related changes that are
doing the same kind of thing is fine.   Think about how others with
changeset-watching tools will decide to look at or not look at your
changeset.  That's easier said than really described of course.

For me, the biggest thing is to keep the geographic extent limited.  A
few square miles is still mostly the same place, but changing things 50
miles or hundreds of miles apart should be separate, to keep the extra
bounding box area with no changes smallish.

Changesets being pretty big geographically is fine if the change is
well-described by the changeset comment and especially if it is
uncontroversial.  To be, uncontroversial means that if 100 experienced
mappers who sort of knew the area looked at it, 95 would say you did
everything basically right enough that nobody should be paying
attention.  The more it strays from uncontroversial the better it is for
a changeset to have more singularity of purpose.

As an example, I sometimes end up adding a few stores here in there in
several town centers, spanning 10 miles - which is still close by my
local area's standards.  In this case, I'm adding store that are there
and taking out ones that are gone, and using established tags, so nobody
would object, and I don't worry.

I might be doing retagging of cell towers (that's in en_US; in en_GB I
mean mobile phone masts) soonish, changing man_made=tower to
man_made=mast.   That's perhaps slightly controversial (alhhough
following consensus on talk@ and tagging@), so I'd limit that changeset
to just that kind of change, even though it will cover a biggish area.

So I think your example of 3 square miles of fixing road geometry is
fine.  I would just avoid adjusting tags in the same changeset, and make
the comment clear that it's about straightening roads.





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

Re: [Talk-us] Fwd: Re: [OSM-talk] Slack

[Greg Troxel]

Charlotte Wolter  writes:

> Really nice discussion of the issues around using for-profit tools
> in an open-source organization.

The for-profit point isn't really the core issue.

IMHO the big issues are

  the use of non-Free software on servers

  the use of non-Free software on clients

  asking people who participate in OSM to enter into an agreement with
  some entity other than OSMF (or OSMF-US etc.)

So OSMF deciding to pay a company to provide hosting services and
sysadmin to support Free tools (such that people can use it without
signing a contract with the hosting company) would be fine.  Even having
non-Free server code and Free clients, with no contracts, would be
better.

(I have no real idea about slack, except that it seems to be a
walled-garden type place.)


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

Re: [Talk-us] Caliparks re-tagging paths?

[Greg Troxel]

Kevin Kenny  writes:

> This isn't a matter of "get off my lawn." It's a matter of "there's no
> promise that there's a path there at all."

I think you're making a separate argument, that when there's some
maybe-path that's indistinct, and not clearly followable, then probably
the mapper should decide that it doesn't exist and not map it.  If
that's being done out of a desire to accurately map the world, I suspect
everyone is fine with that.

The case being discussed is when there is a path on the ground, and it's
just as obvious and actually there as many other paths -- but the
authorities don't want it used.   There are such paths around me, and
the authorities have told me they don't want them on maps :-)

I think most of the commentary has been along the lines of "What if
there were no rule prohibiting the use of these paths, and no official
discouragement -- would the desire to suppress them be different?"  It
seems to me that the entire discussion arises from people not wanting
maps to show some paths even when the paths are there.


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

Re: [Talk-us] Caliparks re-tagging paths?

[Greg Troxel]

Alan McConchie  writes:

> Thanks everyone for your strong but sincere criticism so far. In the
> thread here on talk-us, I explained _what_ we were trying to do, but I
> didn't explain very much about our rationale: _why_ we think this is
> an important idea. The wiki proposal explains that a little bit
> better, as does my email to the tagging list.

I think it would help if you set out your goals, rather than your
mechanism.  I think people are generally sympathetic to recording true
information about the world (that an authority disapproves of a
particular trail).  But, I think many see an element of censorship here,
in terms of trying to hide information from standard consumers of data.

It seems the consensus on talk-us was to use access=no (if usage is
indeed prohibited in some formal sense).  And there are discussions
about some other additional tags to denote positive or negative official
status.

> I know that there are a wide range of opinions within OSM, but I want
> to make it clear that we don't think we were "breaking" OSM data for
> anybody. We were applying the knowledge of local, on-the-ground

I see it as very much breaking data, intentionally.  Several have talked
about how the intent was to cause trails that actually exist to
disappear from maps made by others from the database.  That's the basic
problem and why so many are unhappy about this.

> experts in order to better describe the world within the free-form
> tagging system that exists within OSM. Remember that there are no hard

While the tagging system is free form, there's a very well established
notion of adding access, surface condition, and other nuances by
additional keys that if not understood do not break the main concept.

So the disagreement is really about whether highway=path includes as a
main concept a trail that really exists that you can really walk on, but
with the detail that the authority doesn't like it.

Another problem with wanting to pivot the main tag to the thing you care
about is that there are many people with many concerns.  Why shouldn't
there be highway=unpaved_path so that those don't show up on other
people's maps?  Or a dozen other variations?

> and fast rules within OSM, only informal standards and common
> practices. Please also note that the official proposal process does
> not require anyone to have a new tag approved before they start using
> it. Also see: https://wiki.openstreetmap.org/wiki/Any_tags_you_like
> 

That's true for using new tags for new objects.

It's not true for suppressing data that others have entered.  That's the
concerning part of this whole situation -- party A has the intent is to
control how party B renders data entered by party C, without B or C's
consent.

I think the $64K question is: Do you see it as central to your goals to
cause maps rendered by others to omit these trails, even if those others
don't want to omit them?  Or are you content to have advisory metadata
that people are encourage to use (in routing, and in rendering, like how
access=no works now)?

-gdt, unaffiliated mapper



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

Re: [Talk-us] Caliparks re-tagging paths?

[Greg Troxel]

There seems to be some wiki-agitation going on about a "proposed tag" of
social path.  Perhaps everyone who is opposed might want to look and
register opposition, unless they are more opposed to wikifiddling than
to this tag :-)

https://wiki.openstreetmap.org/wiki/Proposed_features/Social_path


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

Re: [Talk-us] Caliparks re-tagging paths?

[Greg Troxel]

Mike Thompson  writes:

> On Thu, Mar 24, 2016 at 4:26 AM, Marc Gemis  wrote:
>
>> They tagged them as "social_path", according to their blog entry [1]
>>
> Totally unacceptable.  OpenStreetMap maps what is observable on the ground
> (generally). If they:
>
> 1) Don't want that trail to exist, they can restore that area to its
> natural state, and *then*, delete the data from OSM.
> 2) Don't want people to use those trails, they can place "no public access"
> signs at the places where these "unofficial" trails join the "official"
> trails, and then add the appropriate "access=* tags to OSM as others have
> suggested.
> 3) Simply do not want these to show up on their map, they can do some post
> processing of the OSM data after export, but before rendering
>
> I often map unofficial trails based upon on the ground survey with GPS and
> camera supplemented with Strava and BIng.  It is great to have the data in
> there for my personal use and that of others who like to hike the back
> country, but I also want it to be there for search and rescue, wildland
> fire fighters and other emergency personnel. In effect removing this data
> by using a tagging scheme that no one but the editor in question
> understands is a huge disservice.
> Mike

Mike (and Frederik, and many others) is entirely correct here.  The real
problem is CaliParks breaking data for others, and another view is that
they are not just tagging for the renderer, but tagging for their
renderer only.

It has had zero effect on OSM data, but my local Conservation Commission
has the same policy: on Conservation land, there is a rule requiring
people to stay on official trails.  (I know this because I've read the
rules and becuase I have talked to the Conservation Coordinator.)  Their
maps don't have the unofficial trails, but OSM has most of the more
obviosly visible ones.  I haven't gotten to it, but have more or less
decided I'd put access=no on the unofficial trails.

There are two things that could happen.  One is access=no, we can both
do that and allow it without per-trail signs.  A published official map
and rules suffices; the point is that an ordinary person can determine
what is and is not allowed - it doesn't have to be obvious at any
particular physical local.  (My town tends to have a signboard at
trailheads with a map and rules; this is really not hard to figure out.)

Another is that there could be some sort of additional positive tag,
like officially_maintained=yes, added to trails that a landowner
declares to be usable.  The real point is that these should be extra
metadata, not changing the primary tag.

Finally, I think the notion that omitting actual trails from maps does
not serve the cause of safety.   It makes it harder for map users to
stay oriented, especially if they are using paper maps without GPS.
Having trails marked as not allowed makes it easier to navigate.

And ultimately, putting up no entry signs at unofficial trails is going
to be more effective than trying to suppress map data.


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

Re: [Talk-us] [Imports] Boston, MA, USA addr:housenumber Import

[Greg Troxel]

Jason Remillard  writes:

> The licensing link says the following, it is kind of weird.

indeed.

> "The City of Boston recognizes the value and benefit gained by sharing
> GIS data. Although the City has made reasonable efforts to provide
> accurate data, the City makes no representations or guarantees about
> the accuracy, completeness, or currency of the information provided.
> The City of Boston provides this data as is and with all faults, and
> makes no warranty of any kind. Each user is responsible for
> determining the suitability of the data for their intended use or
> purpose. Neither the City nor its affiliates, employees, or agents
> shall be liable for any loss or injury caused in whole or in part by
> use of any data obtained from this website. The GIS data is updated
> and modified on a regular basis and users are encouraged to report any
> errors to the City."

It's weird because it's not actually a license.  There's no grant of
permission to copy, to make derived works, or to redistribute.

The liability text is also weird, in that it's just an assertion, not a
contract.

Being "encouraged" to report errors is fine.


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

Re: [Talk-us] [Imports] Boston, MA, USA addr:housenumber Import

[Greg Troxel]

I should point out that I'm not opposed to this import or address
imports in general; generally, I am supportive.  But, I think the doing
an import right is vastly harder than someone who hasn't been through
one thinks, and that it's good to iterate on approach and data quality,
and not rush or have a deadline/planned completion time.

These comments are partly based on the Mass buildings import, which I
think was hugely successful.  The data was spot checked by lots of
people and found to be very good, it was added in a way which avoided
changing any hand-mapped data, it's led to mapping missing subdivisions,
and we've had basically zero reports of problems from it.


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

Re: [Talk-us] [Imports] Boston, MA, USA addr:housenumber Import

[Greg Troxel]

Roman Yepishev  writes:

> The wiki now contains updated files that set the postcode and add
> a fixme tag to a building in case it already had the number that does
> not match the official information from SAM.

How many fixme tags would there be?
How many of these fixme tags have you field-checked?
For what fraction of them were the city data correct?

This is a serious question; we know most MassGIS data is right, but we
haven't qualified the city db yet.



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

Re: [Talk-us] [Imports] Boston, MA, USA addr:housenumber Import

[Greg Troxel]

Clifford Snow  writes:

> 4) Is it really necessary to upload that many notes during the import? if a
> building is missing, can you add a node with the address information
> instead of leaving a note?

I am opposed to adding notes from bulk data.  There are already a lot,
and when they are from a human, that's fine.  But database-generated
notes are spam.

Publishing scripts to generate local notes about a data source for those
who want to look sounds good - without changing the map db or notes db.





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