from:"Greg"


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

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

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


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

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

2020-08-30 Thread 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

2020-08-30 Thread 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-au] Working with local government

2020-07-21 Thread Greg Dutkowski

Thanks, I'll check it out.
Greg Dutkowski
+61 0362238495/0408238495
1 Cascade Road, SOUTH HOBART.


On Wed, 22 Jul 2020 at 12:48, Andrew Harvey 
wrote:

> Richard Fairhurst posted something very relavent to this topic at this
> https://twitter.com/richardf/status/1285590975511957504 in particular
> http://theodi.org/wp-content/uploads/2020/07/2020-05-Providing-data-to-OpenStreetMap.pdf
>
> On Thu, 9 Jul 2020 at 14:52, Greg Dutkowski 
> wrote:
>
>> Hi,
>> Bicycle Network Tasmania are trying to improve the quality of cycling
>> infrastructure information in OSM.
>> Much has been done by volunteers in various jurisdictions, and we have
>> done lots locally, but the tagging is quite complex for cycle paths and not
>> always correct.
>> Local councils are responsible for much of the infrastructure, but they
>> usually have little interaction with OSM.
>> It would be most efficient if the councils GIS data worked in tandem with
>> OSM data so that they kept each other up to date, each storing the info
>> that is most useful for them. For instance, for bike parking, there is
>> little utility in OSM storing the asset numbers and other info that the
>> councils use to maintain their assets (although the ref tag could be used
>> as a foreign key to help keep the two in sych).
>> The Hobart councils we work with are concerned with the quality of the
>> data in OSM and the ability of anyone to change it.
>> Does anyone know of any examples we could learn from of local government
>> itself working to keep OSM data up to date?
>> Thanks.
>>
>> Greg Dutkowski
>> +61 0362238495/0408238495
>> 1 Cascade Road, SOUTH HOBART.
>> ___
>> Talk-au mailing list
>> Talk-au@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-au
>>
>
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Working with local government

2020-07-19 Thread Greg Dutkowski

Hi,
I was thinking of using the ref tag to store the council ID for the object,
and then the council could use the OSMID in their database.
What I was looking for was tools or approaches for keeping the two in sync.
The foreign keys in each system are part of that.
The conflation tools Andew Harvey pointed to may be a way to go.
OSM is so big and diverse it is hard to get your head around all of the
possibilities, so contacts with people who are making conflation work would
be ideal.

Greg Dutkowski
+61 0362238495/0408238495
1 Cascade Road, SOUTH HOBART.


On Mon, 20 Jul 2020 at 12:33, David Wales  wrote:

> Is there any reason against using a custom tag as a linking key?
>
> e.g. some_import_object_id=123456
>
> Then when you need to update the data, you can match the key in OSM with
> the key in the source data.
>
> On 19 July 2020 11:21:04 pm AEST, Andrew Harvey 
> wrote:
>>
>>
>>
>> On Sun, 19 Jul 2020 at 22:28, Greg Dutkowski 
>> wrote:
>>
>>> Hi,
>>> Thanks for everyone's input.
>>> Sebastien best understood what I am trying to do.
>>> It seems inefficient for local government to make their data open and
>>> then hope the OSM community translates it to OSM tagging.
>>>
>> Better for local government to put their data directly into OSM and
>>> maintain a two way link to their data.
>>>
>>
>> While that is certainly welcome, I would never have an expectation of it.
>> I expectat that all public funded works are made open without restrictions
>> on use (of course subject to privacy concerns or other special
>> considerations) so at least the OSM community can use it if we like,
>> anything above and beyond this is a welcome contribution.
>>
>> If a local government is thinking about this, I'd just say engage with us
>> so we can all work together.
>>
>>
>>> Examples and tools from anyone who is trying to keep external data in
>>> sync with OSM will be most useful.
>>>
>>
>> There are some conflation tools at
>> https://wiki.openstreetmap.org/wiki/Category:Conflation but they appear
>> to all need a lot of coding to get up and running.
>>
>
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

[talk-au] Working with local government

2020-07-19 Thread Greg Dutkowski

Hi,
Thanks for everyone's input.
Sebastien best understood what I am trying to do.
It seems inefficient for local government to make their data open and then
hope the OSM community translates it to OSM tagging. Better for local
government to put their data directly into OSM and maintain a two way link
to their data.
Examples and tools from anyone who is trying to keep external data in
sync with OSM will be most useful.
I have had good chats with Transport NSW, but ther do not try and do it.
Maybe they are right, it is too hard.


Greg Dutkowski
+61 0362238495/0408238495
1 Cascade Road, SOUTH HOBART.
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

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

2020-07-14 Thread 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

[talk-au] Working with local government

2020-07-08 Thread Greg Dutkowski

Hi,
Bicycle Network Tasmania are trying to improve the quality of cycling
infrastructure information in OSM.
Much has been done by volunteers in various jurisdictions, and we have done
lots locally, but the tagging is quite complex for cycle paths and not
always correct.
Local councils are responsible for much of the infrastructure, but they
usually have little interaction with OSM.
It would be most efficient if the councils GIS data worked in tandem with
OSM data so that they kept each other up to date, each storing the info
that is most useful for them. For instance, for bike parking, there is
little utility in OSM storing the asset numbers and other info that the
councils use to maintain their assets (although the ref tag could be used
as a foreign key to help keep the two in sych).
The Hobart councils we work with are concerned with the quality of the data
in OSM and the ability of anyone to change it.
Does anyone know of any examples we could learn from of local government
itself working to keep OSM data up to date?
Thanks.

Greg Dutkowski
+61 0362238495/0408238495
1 Cascade Road, SOUTH HOBART.
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

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

2020-06-04 Thread 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

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

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

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

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

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

2020-05-08 Thread 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

2020-05-08 Thread 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

2020-05-07 Thread 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: [OSM-talk] It's time to manage libraries properly in OSM

2020-04-21 Thread Greg Troxel

Kathleen Lu via talk  writes:

>  My local University is the same way. Students and faculty automatically
> get access, but community and alumni can get access by paying fees.
>
> Is access=members an option?
>
> It implies that you have to become a member according to some criteria, but
> that membership is possible for a large swath of people.

I think that's just fee=yes, sort of the same as a parking lot anyone
can use but they have to pay.

(The fact that some people are already prepaid somehow is not important.)

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

Re: [OSM-talk] It's time to manage libraries properly in OSM

2020-04-21 Thread Greg Troxel

Andrew Harvey  writes:

> Currently we can already mark if the library is open to the public on not
> (access=yes means open to the general public), but it's unclear how say a
> school library or library restricted to attendees of an educational
> facility like a university should be tagged (is it access=private since
> only those people attending the institution have been given permission?

If a library is open only to registered students, then access=private is
in order.

I don't think access=customers is valid.   If there is a restaurant that
is open to the public, and they have a parking lot, and you can only
park in it if you are going to the restaurant, then access=customers
makes sense.

A key point for access=customers is that anybody may choose to be a
customer.  If you can't decide to be a customer, that's what private
means.

Arguably, the most important things to do are:

  ensure that all open-to-public libraries are on the map

  ensure that rendering and search de-emphasizes access=private libraries

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

Re: [talk-au] Anzacathon and mapping possibilities

2020-04-21 Thread Greg Lauer

Hi Daniel,

As both a (very amateur) military historian who has visited many of
battlefields/CWG's through the Asia Pacific, Africa and Europe, as well as
an Open Data proponent, I really like what you are trying to do. But...

The terms and conditions of OSM in relation to data imports is fairly clear
- unless the data is already licensed under an Open Data Commons Open
Database License (ODbL) then you will need (preferably written) permission
from the copyright holder.

https://wiki.openstreetmap.org/wiki/Import/Guidelines#Step_3_-_License_approval

A cursory glance at each of the providers websites does not indicate that
they have licensed under ODbL. Yes, this is pain, but it is the only way
OSM can ensure that the data can be legally used. Feel free to send them an
email asking if they will give permission to make there data available in
OSM. I can send you a template letter that explains the licensing
conditions to the copyright holder. The CWGC data set would be great as a
global dataset!

The use of OSM within a web service (such as the CWGC) has no relationship
to whether we can incorporate and/or import the said data sets into OSM.
Again unless explicit permission is given it will need to be requested.

Do you actually need to integrate the data sets into OSM? You seem fairly
talented at data wrangling and my suggestion would be build your web
services using OSM as a base map, and make the ancillary data available as
a separate overlay. This way you will not potentially breach the terms and
conditions of the OSM licence (but still please check with the data
providers that you can use that data in this way). There are multiple other
ways that you can display the data sets with out actually integrating into
OSM.

I look forward to seeing the completed product!

Cheers

Greg

On Tue, Apr 21, 2020 at 4:10 PM Daniel Pocock  wrote:

>
>
> On 21/04/2020 02:25, Warin wrote:
> > On 20/4/20 9:10 am, Daniel Pocock wrote:
> >> On 20/04/2020 00:49, Andrew Davidson wrote:
> >>> On Mon, Apr 20, 2020 at 7:52 AM Daniel Pocock  >>> <mailto:dan...@pocock.pro>> wrote:
> >>>
> >>> The CWGC copyright notice appears to be compatible with a bulk
> import of
> >>> their cemetery data.
> >>>
> >>>
> >>> The copyright notice explicitly says you can only use it for personal
> use.
> >> "Personal use" is one of those things that can be vague.  They don't
> >> elaborate.
> >
> > 'They' don't need to elaborate.
> > Most, if not all, lawyers will tell you that it excludes 'business use'
> where it is used to generate money.
> > OSM requires that OSM data can be used to generate money.
> >
> > This, to me, clearly says that the data cannot be used in OSM.
>
> Agreed, but it is safe for people to explore the data at home as part of
> the Anzacathon
>
> >> All these sites include a lot of photos and other material.  They may
> >> only apply the strictest definition of their license to those things, it
> >> could be worth contacting them to find out if they are happy for
> >> OpenStreetMap collaboration on the location data.
> >
> > Go right ahead and contact them.
> >
> >> The Anzacathon itself is a personal and non-profit activity that I've
> >> contributed to as a volunteer and I've cited all the data sources so I'm
> >> quite comfortable with the licensing.
> >
> > You may be comfortable.
> >
> > Will OSM lawyers be?
> >
> > Will the authors and lawyers of those data sources be equally
> comfortable?
>
> I agree with your concerns for the specific case of import to OSM
>
> I notice that AWM is using OSM on their site but CWGC is using Google
> Maps on their site.  An initiative to contact the CWGC might look at
> something broader than this data set and look at the general question of
> helping them operate without Google, like AWM.
>
> The UK Government also has a strong commitment to Open Data and this
> would be a factor for CWGC
> https://en.wikipedia.org/wiki/Open_data_in_the_United_Kingdom
>
> Based on the above, what are the things that people can do
> constructively with the data as it stands?  Any suggestions would be
> really welcome.
>
> Hopefully I will have some more time to work on it myself this week, I
> was planning to make a simple function for people to search for war
> graves and monuments within a given radius.  That doesn't exist on any
> of the sites right now.
>
> Regards,
>
> Daniel
>
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au
>
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [OSM-talk] Strava high resolution heatmap

2020-03-31 Thread Greg Troxel

Jmapb via talk  writes:
> The latest I've heard is this thread from last November:
>
> https://lists.openstreetmap.org/pipermail/talk/2019-November/083563.html
>
> Rodrigo Davies at Strava says they "don't currently see a problem" with
> using the heatmap for mapping. A screenshot of this communication was
> added to the wiki at https://wiki.openstreetmap.org/wiki/Permissions/Strava

Someone saying they "don't see a problem" is hardly a license grant,
even if they are authorized to bind the company.

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

Agreed that your approach is very reasonable.

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

I am very much opposed to adding paths based solely on Strava for
exactly these reasons.  It does seem reasonable to use as a clue for
going into the field to survey something that might or might not exist.

Additionally, around me there are problems with people (mostly on
mountain bikes) trepassing onto posted properties.  If these tracks show
up on strava, even if they are actual paths, mappers are prohibited from
performing on-ground verfication.   This is another reason to be
uncomfortable with strava-only edits.

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

Re: [OSM-talk] Changeset Governance [was: Announcing Daylight Map Distribution]

2020-03-23 Thread Greg Troxel

> Subject: Re: [OSM-talk] Changeset Governance [was: Announcing Daylight Map 
> Distribution]
> From: Frederik Ramm 
>
>> Nothing against the idea but what happened to the good old source tag
>> where source=survey would point to mappers on the ground, and
>> source=XYZ
>> aerial imagery would point to armchairing?

I'm very sympathetic to knowing the on-ground-ness of a change.  But I
think it's shades of gray.  This list illustrates what I mean:

* armchair

a place I have never been to, and which is so far away that I am not
familiar with the customs.  An example would be me (US) editing in Africa.

* country-armchair

as above, but I know the country norms.  Me editing in Glacier National
Park.

* local-armchair

as above, but I know the region norms.   If I edited some town in MA
that I haven't visited (perhaps because I was going to visit), but I
generally know how things are.

* visited but mapping done by imagery

Here, I am editing a place where I've been at some point reasonably
recently and have some clue, but my edits are based on imagery.
However, my recollection is good enough to avoid most of the armchair
issues.   An example is me fixing up crosswalks and sidewalks two towns
away, but not from field mapping notes.   I don't consider this
armchair, but it's iffy.

* editing soon after a visit

I got someplace, maybe make notes, maybe remember, and edit based on
some combination of imagery, gpx tracks, notes and memory.   I think
this is squarely not armchair.

* editing while there

Actually using an editor while being in the place being edited.



I would basically split this into three armchair and three not armchair.




So basically I think source including imagery does not really imply
"armchairing", in that the use of imagery is not the point, but a lack
of familiarity with what's on the ground.  I almost always load and look
at imagery when editing after being in the field.  I line up ways from
imagery when that works, becuase I have come to believe from experience
(with specific imagery sources) that this is more accurate than my gps
tracks.

(I have been experimenting with raw GPS data and post-processed PPP
solutions, and those I think are close to good imagery.)




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

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

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

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

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

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: [OSM-talk] Taking a break and a call for help

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

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

2020-03-21 Thread 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: [OSM-talk] Taking a break and a call for help

2020-03-21 Thread 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 mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

2020-03-17 Thread Greg Troxel

I think it's reasonable to mark something as

  this was used by an import long ago, isn't used by mappers now, and
  the existence of it shouldn't be taken as a clue that it's current
  good practice

but I think this should also be done in a way that is not unkind to or
judgemental about long-ago importers.  That was a different time, with
different norms, and reasonable people were doing what they thought was
a good thing.  (In my view, mostly it was good, and the issues are
minor, but that's not really the point.)

So something like

  historical_import

to basically say "people used these tags in imports long ago, but there
is no present use, import or otherwise".




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

Re: [Talk-us] Tagging historic US routes

2020-03-13 Thread Greg Morgan

Only one person cared about US 80 in osm.  I have deleted portions of the
route because parts of it are artificial ways to make the route render.
These artificial ways interfered with other mapping.  You can do what you
want with the route including deleting.

On Thu, Mar 5, 2020 at 6:47 PM Tod Fitch  wrote:

> This weekend I drove part of AZ-79 and noticed that Arizona has now put up
> some “Historic US 80” signage. On the sections of highway I drove, every
> occurrence of a AZ-79 route marker now also has a historic US-80 route
> marker. (Back in the day that highway was dual signed as US-80 and US-89
> but I guess nobody cares about having historic US-89 markers at present.)
>
> I was in a rental car and eventually figured out how to get Apple CarPlay
> setup so I could use the OSM based Maps.me app to show the roads I was on.
> In doing so I saw that Maps.me was showing the road with dual highway
> shields: A AZ shield with 79 and a US shield with 80. Since US-80 was
> decommissioned a long time ago (at least in Arizona and California) this
> seems wrong so I thought I’d look at the tagging.
>
> The tagging is on a route relation [1], at least I don’t see tagging on
> the individual way segments that would render as “US 80”.
>
> How should this be tagged?
>
> Casting about for examples of what to do, it seems that the Lincoln
> Highway [2] relation is quite different. And US 66 in California has no
> historic route relation at all, just the current county road route [3].
>
> There is a German page on the wiki about “route=historic” [4]. My reading
> of a machine translation of it implies that instead of “route=road” the
> historic US 80 relation should have “route=historic” and “historic=road”.
>
> Suggestions?
>
>
> [1] https://www.openstreetmap.org/relation/9230611
> [2] https://www.openstreetmap.org/relation/3958115
> [3] https://www.openstreetmap.org/way/205719338
> [4] https://wiki.openstreetmap.org/wiki/Tag:route%3Dhistoric
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [OSM-talk] #AttributionIsNotOptional experiment on OSM France tile servers

2020-03-08 Thread Greg Troxel

Mario Frasca  writes:

> I would say that 1 in 25 is low enough as not to be considered
> "defacing" a web site.  what text have you used, concretely, which had
> the impact you describe?  in my opinion the shortest, the better, and
> I guess you did NOT use »It looks like this site forgot to put the
> required attribution in this map corner, so we added it for them. Thx
> for using OpenStreetMap !«, did you?  it was in French, wasn't it?

Also, I have seen on many sites google maps with an "API Key Required"
watermark.  This really seems like a similar situation.

So perhaps Christian could put a fairly loud attribution watermark over
the tiles, so it's basically functional but attributed.

Overall, I think this is a great experiment, and the combination of
failure to attribute and use of donated tile services is particularly
worthy of addressing.

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

Re: [Talk-us] Mapping for emergency services

2020-02-05 Thread 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?

2020-01-25 Thread 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] When is your doctor a clinic?

2020-01-24 Thread Greg Morgan

Brian,

That's my US American understanding of a clinic.  A clinic is not a
hospital and not a "doctors office".  But If I cannot get into my doctor or
if an individual does not need to go to the emergency room of a hospital,
then a clinic is a place to go.  For example, Honor Health is part of a
hospital system.  They are adding these "clinic" type places all over the
place as in here
https://www.mapillary.com/app/?lat=33.6404930901=-112.0118460302=17=FJ_1oHqz8x2c1-PziWhxSQ=photo=0.4913798647410984=0.548466145091522=0
In this case, they bought out another clinic and replaced it with their
Honor Health brand.

You will need to zoom in on this image
https://www.mapillary.com/app/?lat=33.67662935172414=-111.97772731602434=17=sEr2RqD5xZYGSZGEej8oJw=photo=0.8085766039159952=0.517578833862374=2.486737400530504
There
is also surgery center's.  Still not a hospital but invasive procedures are
performed at these locations.  A surgery center is cheaper than a hospital
per insurance dictates.  In this case you could go while with POIs.  Some
of these surgery centers are next to a string of retail POIs or may be in
the same wing of a building with retail space.

Don't know.  Some day I will sit down and map those.  I am just not
interested at the moment.

Regards,
Greg




On Fri, Jan 24, 2020 at 6:33 AM Brian Stromberg 
wrote:

> When I hear “clinic” in reference to a healthcare facility, I think of
> “urgent care” clinics, and I think there are about six urgent care clinics
> within a 20 minute drive of my local hospital. These are usually staffed
> with nurses and Physicians Assistants rather than MDs. It’s pretty common
> in the US for people to use these rather than the local emergency room, or
> even in lieu of a primary care doctor. Having them on OSM seems important
> if people need immediate care that doesn’t rise to the level of a hospital
> visit. For example, I took my mother to one near me when she had a fall (at
> her request, I might have preferred an actual hospital, but it wasn’t a
> great time to argue...). They often serve you faster and there is less
> administrative processing involved.
>
> Just wanted to share an American perspective.
>
> On Fri, Jan 24, 2020 at 7:56 AM Philip Barnes 
> wrote:
>
>> On Fri, 2020-01-24 at 00:51 +0100, Frederik Ramm wrote:
>> > Hi,
>> >
>> > On 1/23/20 22:42, Paul Johnson wrote:
>> > > There may be a disconnect with what the US (or that spammer)
>> > > means.
>> > > Could I get a clarification on the difference between "doctors" and
>> > > "clinic" as you understand it?
>> >
>> > Personally (and in my country - Germany) there's precious little I
>> > would
>> > tag as a clinic; in everyday language we use the (german version of)
>> > the
>> > word clinic more or less synonymous with "hospital", with the
>> > possible
>> > exception that we'd also apply clinic to something that deals
>> > exclusively with non-illness-related things like e.g. a beauty clinic
>> > or
>> > a drug rehab clinic. In my language, a clinic would always be
>> > something
>> > where you can (and usually do) have a bed and stay for longer until
>> > the
>> > treatment is over. A building with a couple of different medical
>> > practitioners might be a "Gemeinschaftspraxis" ("shared practice") or
>> > perhaps an "Ärztehaus" (doctors' house) but not a "Klinik". Then
>> > again
>> > these would hardly ever be open 24/7...
>> >
>> > I'm not trying to apply my understanding of medical establishments to
>> > the US - just asking what the general understanding is on your side
>> > of
>> > the pond. Does Jmapb's distinction sound more or less ok for others
>> > too?
>> > He wrote:
>> >
>> Even in the UK, where OSM originated, clinics are quite rare.
>>
>> A clinic is where outpatients go, usually referred by their doctor to
>> see a specialist.
>>
>> The on the ground reality is that most clinics take place within
>> hospitals.
>>
>> Standalone clinics do exist, there is one in my town, but will tend not
>> to exist in larger towns or cities which have hospitals.
>>
>> HTH
>> Phil (trigpoint)
>>
>>
>>
>> ___
>> Talk-us mailing list
>> Talk-us@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-us
>>
> --
> --
> Brian
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

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

2020-01-08 Thread 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

2020-01-02 Thread 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

2019-12-26 Thread 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

2019-12-26 Thread 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] Alt_names on counties

2019-12-25 Thread Greg Morgan

Please don't remove the alt_name tags.  They are useful and not that much
of a distraction or an error  For example, a new freeway was just renamed
for a congress person that helped with many AZ transportation projects.  I
added the alt_name tag so that the South Mountain Freeway can still be
found in a search.  The new name is months old while the old alt_name has
been used for decade.  Not everyone calls Pima County by its full name.
That's why I think that the mapper added the alt_name so that
searches would be successful.

https://www.openstreetmap.org/changeset/78850121

On Wed, Dec 25, 2019 at 6:26 PM Tod Fitch  wrote:

> 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”).
>
> 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.
>
> Thanks!
> Tod
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] TIGER-completeness visualizer?

2019-12-22 Thread Greg Morgan

On Sat, Dec 21, 2019 at 2:03 PM stevea  wrote:

> As the ITOworld TIGER-completeness visualizer at
>
>
> https://product.itoworld.com/map/162?lon=-121.88=37.04=12=true_sidebar=map_key
>
> is no longer supported, does anybody know of a similar "product" that we
> can use to visualize how well we have reviewed TIGER roads (and rail?) in a
> given area?
>
> I REALLY miss that visualizer!  It showed whether highway=* ways were
> "touched in the last three years," whether the tiger:reviewed=no tag was
> removed and so on.  It was very well done and quite informative.
>
> I suppose a dedicated renderer could be built, that's pretty ambitious,
> though it is a worthy project, imo.
>

History:
* First there was Andy's green/red Tiger fixup map.  That was a great
simple map. The map would go from red to green when you killed the reviewed
tag.
* Mapquest picked up this map for a bit but it died when the group was
decommissioned.
* Itoworld was a nice version that added many more colors and the date last
touched.  The map was damaged when certain tags were no longer saved with
each edit.  These were removed in the background.  I started removing all
the Tiger tags because most of the map started turning black.  You could
tell what was edited or not.  The map almost reverted to Andy's map.
*There was a Battle Grid map. The original was lost but there is a
replacement that you have to run by yourself as far as I can tell.
https://wiki.openstreetmap.org/wiki/TIGER_Battlegrid
https://github.com/iandees/tiger-battlegrid

My problem with Battle Grid map was that the the colors were too light when
you revised Tiger data.  I liked the idea because it reminded me of the Who
Did It Map. Something simple like a grid but use two colors like the
original fixup map but with no fading.  All each tile at zoom 16 needs to
do is change color and tell you how many more ways need to be touched.
Most of the tiles would be red until you touched all the roads.  Then the
tile would go green.  Again my approach is to removed all the Tiger tags
because the street names have been expanded.  I don't do this on major
connecting highways because I am not sure that all the routes have been
defined yet.  Tiger will have some of that route data in the list of tags.

> Bonus points for your best guess at when OSM will eventually complete a
> full TIGER data review.  I'll start:  at the rate we're going now, 2045?
>

April 2050  for nodes
June 2028 for ways
based on Ben Discoe's burn rate calculations.
https://www.openstreetmap.org/user/bdiscoe/diary/44192
https://docs.google.com/spreadsheets/d/1HiC1-ixx30tbwgI27RJt1SvvK80BBRkLOg98Qcb0SD0/edit#gid=1034182050

Ben's spreadsheet mentions all these mappers except for balrog-kun for the
western states name expansion bot.
woodpeck_fixbot
TIGERcnl
jumbanho
jremillard-massgis
bot-mode
DaveHansenTiger
balrog-kun

I often use this list of mappers as a way of checking Tiger progress.  Note
that woodpeck_fixbot removed Tiger tags on nodes.  Hence, you have an idea
if the street has been touched or not for most of the cases.

Finally, I am not sure that OSMOSE would be a way to track Tiger data.  I
like the positive idea for moving forward.  I suppose that a pin would
render on every Tiger way might work.  The cycle times on some areas a
really slow in OSMOSE.  You'd have to close all the pins after each edit to
see how you are doing.  That effort adds to the pain.  I think the
challenge for the U.S. project is that most of these maps have been
maintained outside the U.S.  If implemented, I am not sure how long OSMOSE
would provide the service.

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

Re: [OSM-talk] What does WGS84 mean for openstreetmap these days?

2019-12-20 Thread Greg Troxel

"Jóhannes Birgir Jensson"  writes:

> Well the current issue in Iceland is a error of 50 cm between 1993 and
> 2016 due to crust movements. So it's less than 2 meters but more than
> one cm.

That's interesting and a useful data point for later discussion about
the points that my message said this discussino isn't about!

> What is your accuracy limit if 2m is just unacceptable but a
> centimeter is?

There are several issues that must be addressed over time for improved
accuracy.  I am not claiming that any particular accuracy is required
and I am very definitely NOT suggesting that OSM adopt accuracy
requirements for data.

I am not following where "1 cm" came from in this discussion and don't
think it is relevant.  (I do think that asking the question of how to
get to 1 cm eventually is interesting, but I see that as a separate
issue.)

My point is that our current definition of "WGS84" has ~2m of fuzz
*intrinsic to the definition* because (as discussed at length on the
proj list) saying "WGS84" means "these coordinates are in one of six
datums and I am not telling you which".  There is no need for OSM to
have this definitional uncertainty, and I think that is both the biggest
issue and the easiest to address.

Regardless of the definition, it is clear that there will be data of
varying accuracy in OSM.  I am not objecting to that reality, or asking
that OSM adopt accuracy standards.  There seems to be a shared norm that
more accurate locations of  nodes are preferred to less accurate
locations.

I think there's also a shared belief that wildly inaccurate nodes are
not helpful; if I added a POI that was 10 km off (in an area where there
are many things between the mapped location and the real location), then
that is probably a bad thing to have done.  But if I add a POI that is
100m off, someone might fix it, but I don't expect they would tell me
that I should not have added it.  Certainly this is true at 10m error
(the lack of outrage; it might or might not get improved).

So about the narrow issue of the definition of OSM's coordinate
system, do you prefer

  leaving it defined as "WGS84", so that coordinates have to be treated
  as having an intrinsic uncertainty of several meters

  changing it to "WGS84, and in particular the revision currently in use
  by GPS", allowing one to treat the datum as relatively precise and
  thus only question the accuracy of the coordinates themselves?

  something else?

Note that the second option allows one to transform e.g. precise
coordinates from a geodetic control point to add to OSM.  (Yes, I
realize one could transform to a particular realization anyway.)

In all seriousness, I cannot tell if you object to this first step, or
are making comments about some later step that might happen, or at
talking about the issues of OSM perhaps adopting accuracy requirements
(not on the table!0, or something else.

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

Re: [OSM-talk] What does WGS84 mean for openstreetmap these days?

Yantisa Akhadi  writes:

> To add more challenges to this issue is imagery offset
> . The value
> can even be varied from tiles to tiles, that we often need to shift the
> object a couple of meters away. In a remote area, where there are no GPS
> traces as a reference, satellite imagery is often the only reference even
> when possibly it was a couple of meters off.

Certainly that is a challenge.  But, once the datum is defined clearly,
then it is work to figure out, but not a question of ambiguity as to
what is desired.

I am unclear on whether most imagery offset issues are due to imagery
being in a datum other than modern WGS84 (and not transformed), or just
due to errors.  In Massachusetts, US, it seems most of the imagery
sources are pretty well aligned.  But this cries out for actualy
checking better!

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

Re: [OSM-talk] What does WGS84 mean for openstreetmap these days?

"Jóhannes Birgir Jensson"  writes:

> I don't think we can or will be providing accuracy up to cm when most
> of the stuff we map from our chairs is off by a meter or two anyways -
> the beauty is that it doesn't matter for 99,99% of users. If a
> centimeter matters then we are probably dealing with legal matters and
> there OSM makes it quite clear it is not suitable for such.

My actual proposal, as opposed to the things I pointed out I wasn't
proposing, is about removing the ~2m uncertainty that exists from our
current definition.

As for cm level, OSM does not have accuracy specifications and won't.
Some people like to be accurate, and others like to add lots of detailed
tags.  Between us we have great map.  I don't agree that anybody who is
trying to be more accurate is necessarily concerned with something that
is "legal".  I would expect many people would like to see better than 2m
accuracy.

Certainly cm-level is very difficult, and I see that as being pretty far
out in the future.

You didn't comment on the notion of defuzzing the reference to WGS84, so
I'll assume you are ok with that.

> Also regarding the accuracy, as another fast moving country Iceland is
> actually splitting in the middle and so it edges west and east and
> south as well, depending on where you are in the country. We've had 3
> official national datums now, ISN93, ISN2004 and ISN2016 (helpfully
> naming them after years). The fact is that pretty much everything is
> still running in ISN93, ISN2004 saw very little uptake and ISN2016 has
> started very slowly.
>
> So for Iceland we do know that we are never going to achieve a
> centimeter accuracy, pretty much ever, and don't expect a free people
> sourced geographical database to reach it.

Interesting about the datum history.  But this is the cm strawman I
wasn't talking about, not the 2m issue.

I would not be surprised if in 20 years OSM had some approach to
coordinates of crust-fixed points.

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

Re: [OSM-talk] What does WGS84 mean for openstreetmap these days?

Simon Poole  writes:

> Thus is a slightly tricky subject and it is not going away.
>
> For another aspect of it see
> https://www.openstreetmap.org/user/StephaneP/diary/390290

Thanks -- I had not seen that.

I would say that to be pedantic, there is a minor error in the post, in
that OSM coordinates are by definition WGS84.  Agreed that when people
add points with coordinates that are in other datums, then the points in
the database have errors.

I am in the process of figuring out how to deal with this, as accurate
locations in my state basically come from using the state's reference
network, which gets you NAD83(2011) epoch 2010.0.

> Essentially in some cases we are using imagery that isn't actually using
> WGS84 as if it was (fsvo of WGS84 as you correctly point out) and we
> currently don't actually have a way to correct this . And yes while
> continental shift is for most countries smaller than all the other ones
> when adding geometry, for Australia this not necessarily true.

That's true for how people with editors generate coordinates.  It seems
quite possible to adjust imagery to WGS(G1762) in editors, and arguably
that should happen.  I wonder though how often imagery is sufficiently
accurate in some national datum that this matters.  I suspect it's more
and more often.

In my message, was really trying to deal with the issue that by saying
"WGS84" instead of "WGS84(current realization)", OSM has a built-in
uncertainty of about 2m before we even start talking about where data
came from.  That seems easy to take off the table with zero workflow
changes.  At least then there will be a clear definition of what's
intended.

Actually changing the notions is much more difficult and I was trying to
separate the easy step from the harder ones.

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

[OSM-talk] What does WGS84 mean for openstreetmap these days?

(This is a long and complicated subject and I am intentionally asking
only part of the question.)

It's been said from the beginning that coordinates in the openstreetmap
datbase are in "WGS84".  That more or less meant "what a GPS receiver
showed", back in the days when GPS was the GNSS system of choice and
accuracies were low compared to talking about versions of WGS84.

In discussion on the proj list, it seems the consensus view is that
WGS84 is now a term that refers to any one of the 6 realizations of
WGS84 over time.  This makes sense when you have data that is merely
labeled WGS84, without a more specific label such as WGS84(G1762).  This
means that WGS84 is considered low accuracy (because the original was),
and thus any transforms involving it are assigned high error values.

This page has a good overview of the various WGS84 realizations and
their relationship to ITRF realizations:

  https://www.e-education.psu.edu/geog862/node/1804


As normal people (or at least normal nerds) get access to more accurate
positions, this question begins to matter, as in North America positions
in original WGS84 and modern WGS84 differ by more than a meter.

I should note that now that WGS84 has converged to ITRF, and new ITRF
realizations seem to be at most cm-level changes from previous ones, I
do not expect future WGS84 revisions to be signficantly different from
either the current one.

So, I wonder if we want to change the definition for OSM coordinates
from "WGS84" to "the realization of WGS84 currently in use by GPS".
That doesn't change older coordindates (and I am not suggesting any
automated changes!!!).  But it does give a notion of what coordinates
should be, both in using them and in producing new ones for editing.  I
expect that this will have zero practical effect for most people, but
will allow higher accuracy for those who are into extreme accuracy.


postscript:

I am intentionally leaving out of this discussion two more issues (which
could result in further changes, with much more complexity).  I list
them so that those with some background in geodesy can begin to ponder,
and to explain that my stopping at the proposal above was intentional.

1) WGS84 is a US datum.  BEIDOU, GALILEO, GLONASS use different datums.
   SBAS systems also use different datums -- WAAS seems to give
   coordinates in "ITRF2000 (current epoch)".  It seems most are
   equivalent to some modern ITRF, with possibly differing epochs.

(I will assume for point 2 that there OSM redefines coordinates to be a
particular ITRF at a particular epoch, probably matching the current
WGS84.)

2) ITRF is global, but objects we map are generally crust-fixed on some
plate.  The US has a (mostly, if you're not in CA) crust-fixed datum,
NAD83, and other countries do too.  This is particularly acute in
Australia which is a notably fast-moving country :-) The modern trend is
for stations to have velocities and not just coordinates.  Over 20
years, this starts to matter.  Several countries are introducing new
national datums that are intended to address some of these issues.  I
don't think it makes sense for OSM to deal with this issue for a few
years.

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

Re: [Talk-us] Trunk VS primary,

2019-12-17 Thread 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

2019-12-17 Thread 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

2019-12-17 Thread 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-au] QTOPO online maps

2019-09-15 Thread Greg Lauer

Just so I am clear on this issue. We are not asking DERM to change the
current CC4 licence. We are asking DERM to give us formal permission to use
the data. This can be as simple as an email from a responsible party at
DERM giving us permission. Am I interpreting this correctly?

Greg

On Mon, Sep 16, 2019 at 11:01 AM Andrew Harvey 
wrote:

> I don't think OSMF will change this requirement, as the reasons for the
> waiver are detailed in the blog post Mateusz linked to,
> https://blog.openstreetmap.org/2017/03/17/use-of-cc-by-data/ are pretty
> compelling.
>
> There had been some hope that CC BY 4.0 sources would be directly
>> compatible with the ODbL. But while neither CC nor the OSMF has undertaken
>> a complete compatibility analysis, we have identified at least one  point
>> of incompatibility and one possible challenge regarding attribution that
>> lead us to our decision to continue to ask for explicit permission to use
>> BY 4.0-licensed material in the OSM project. This is the best path forward.
>
>
>  If you would like a second voice for your enquiry with Gold Coast, feel
> free to loop me in.
>
> On Mon, 16 Sep 2019 at 07:34, Graeme Fitzpatrick 
> wrote:
>
>>
>> On Sun, 15 Sep 2019 at 21:02, Andrew Harvey 
>> wrote:
>>
>>> On Sun, 15 Sep 2019 at 18:05, Mateusz Konieczny 
>>> wrote:
>>>
>>>> See https://blog.openstreetmap.org/2017/03/17/use-of-cc-by-data/
>>>>
>>>> CC BY 4.0 requires waiver
>>>>
>>>> The additional text is confirmation that it is
>>>> actually released under this licence
>>>> and that personal confirmation is not required.
>>>>
>>>
>>> Exactly.
>>>
>>> I reached out to Greg Payne, Director of Land and Spatial Information,
>>> Topographic Data, Imagery and Mapping, DNRM in December 2018 (in case
>>> anything had changed since my prior correspondence), the reply was:
>>>
>>>  The Department’s position has not changed since your previous enquiry.
>>>>
>>>> Consistent with Queensland Government policy, our data is provided
>>>> under a CC:BY 4.0 Licence.  The department will not provide the data under
>>>> an ODbl licence.  It is our belief that a CC:BY licence is sufficient for
>>>> use of our data and we do not accept that OpenStreetMap cannot use our data
>>>> under the CC:BY licence.
>>>
>>>
>>> So unfortunately we're in a stalemate, OSMF says we need a waiver, DNRME
>>> says they don't believe we need one. So we can't currently use DNRME's CC
>>> BY 4.0 open data within OpenStreetMap unless either OSMF or DNRME change
>>> their stance.
>>>
>>> I'm not taking a stab at DNRME over this, they are free to no agree to
>>> the waiver, it's their call.
>>>
>>
>> Thanks both of you.
>>
>> Exactly the same position with my on-going discussions with Gold Coast
>> City Council - they've given us explicit permission to use their data, but
>> can't get their head around our need for a waiver as well?
>>
>> " unless ... OSMF ... change their stance" - any chance / likelihood of
>> that happening?
>>
>> Thanks
>>
>> Graeme
>>
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au
>
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

[talk-au] Paths in Illawarra Conservation Lands

2019-09-11 Thread Greg Lauer

Hi Frederick,

There is 'authoratative' data available for NPWS estate -
https://data.nsw.gov.au/data/dataset?q=NPWS+track===_format=_id==score+desc%2C+metadata_modified+desc
and
we have a waiver -
https://wiki.openstreetmap.org/wiki/Australian_data_catalogue. The problem
is that the data is not up to date, and in may cases conflicts with the
'on-the-ground' conditions. For example a track marked as open in the
database has closed signs and vice versa, or a local Ranger may decide to
close the track. This is common problem with data made available from state
agencies as in many cases there is reluctance to make data public (or they
don't have the resources to manage it).

I think your solution is appropriate in the circumstances but will make the
following comments.

1. Although we can mark as private or similar it really is up to the
rendering engine of the application that the user is looking at to display
this attribution (closed etc.). A quick a review of some of the common
applications seems to indicate this is a problem.

2. Other 'authoritative' data (for example https://maps.six.nsw.gov.au/ and
the 1:25,000 topographic maps) all showing conflicting data around track
and very little information on access rights.

3. The area in question is managed by three entities - state government,
local government and private landholders and they all have conflicting
views on access to the area.

These issues around the mapping of tracks has been an ongoing issue for as
along as people have been creating maps! I am unsure how NWPS think that
can sue someone for creating a track on a digital database (but this is not
the first time they have threatened this). I believe there was an issue
with a commercial publisher a few years back regarding some tracks in
National Park that had been closed. That said, hopefully by engaging with
these agencies we can effect change.

Thanks for taking the time to look into this and present an solution.

Greg

On Thursday, 12 September 2019, 6:23:34 AM AEST, Frederik Ramm <
frede...@remote.org> wrote:

Tony,

On 9/11/19 21:31, fors...@ozonline.com.au wrote:
> The construction and use of unauthorized trails is illegal with large
> penalties (though I have never heard of a prosecution).

Are there sources that are not restricted by copyright that we could use
to determine which trails are authorized and which are not?

> The policy in OSM to map everything that exists ignores the fact that
> not all mapping is in the community interest. I would like to see a more
> nuanced policy.

There are indeed some nuances, for example there is general agreement in
the community not to map the nesting places of rare birds (lest eggs be
stolen), and a similar general agreement exists for things like women's
refuges. This is in addition to the respect for privacy that is shared
by most mappers - where the term "privacy" is generally interpreted
narrowly to mean "things about your life that you cannot see from the
aerial image".

Some people come to DWG claiming privacy because someone has traced
their driveway from aerial imagery; this is not usually a complaint we
entertain.

But the things I mentioned are not really codified anywhere, and there
are often corner cases that lead to lengthy debates. A remotely related
case for example was in Germany recently, where forest management and
tourism authorities had agreed to a careful scheme of "trekking" camp
sites in forests where camping would not normally be allowed. Their plan
was to keep the exact location of these places secret, and require prior
booking by users, who would only upon booking be told where exactly to
find the spot. This was part of the compromise they reached - the forest
authorities didn't want any people camping, the tourism people wanted to
offer something for nature lovers, so they agreed on this scheme which
at least promised that the places would not be overrun. You can imagine
how the story went on - things being kept secret piqued the interest of
mappers, and before too long all the places were mapped
(tourism=camp_site, camp_site=basic, backcountry=yes). The authorities
complained, but of course they have no legal recourse... still, this led
to some discussion in the German mapping community in how far official
wishes/demands for secrecy should be respected.

We certainly cannot respect *every* local government law or else we'd
likely have to purge our maps of all content in China, North Korea, and
some Arab countries, delete all military areas in many others...

It is an interesting topic for a general discusssion. Though in this
concrete case I wonder how to determine whether what looks like a
footpath in the Conservation Lands is legal to use or not... should
*all* the trails drawn in the area be marked access=no? Should we ask
the adminstration for a list?

Bye
Frederik

--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33"

Re: [OSM-talk] handling street names in speech

2019-07-17 Thread Greg Troxel

Rory McCann  writes:

> I don't think this counts as “tagging for the renderer”, which is more
> about adding false data to “make the map look like what you want”
> (e.g. “I want a blue line here, like the `route=ferry` line, so I'll
> use that”).
>
> I think it could be very helpful for place names which aren't
> pronounced the way you pronounce regular English words. e.g. in
> Ireland: “Dun Laoghaire” [dun leary], “Tallaght” [tala], “Youghal”
> [yal], “Portlaoise” [port leash]. This could be a problem even in
> England with places like “Reading”, “Worchester”, “Cirencester”.

I was about to start off by suggesting that the name->IPA database be
separate as it was not clearly geospatial.  After congratuluating myself
for knowing how to pronounce Portlaoise, I came to "Worchester".  In New
England, we have a "Worcester" and "Marlborough" as well, but they are
pronounced quite differently, "w[oo-shwaish] stah'", and the first R in
marlboro is mostly dropped, boston style.  It definitely sounds funny
when pronounced in straight standard English, and I had already
considered extending osmand to have boston pronunciations.

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

Re: [OSM-talk] handling street names in speech

2019-07-16 Thread Greg Troxel

John Whelan  writes:

> One or two are problematic usually as the street name is an
> abbreviation.    For example 1e Avenue in French meaning First Avenue.
>
> Any suggestions on how these should be handled?  This particular
> application is aimed at partially sighted people but I feel we should
> be able to come up with a generic solution.

Two comments:

  osm norms are to expand abbreviations, as I understand it.  So that
  should be fixed first

  Even after that, we have ref tags, and there is often a road whose ref
  is something like "CT 2", "US 1", or "I 95".  I don't really think
  this should be expanded in the database.  Instead, what's needed is a
  table in the application, perhaps centrally maintained in OSM, of how
  to pronounce standardize ref abbreviations.  Putting phonetics of
  "connecticut" on all use of CT or the expanded name is not reasonable.

But I agree this needs help.  I get told to turn on "Court 2" and "Ma
2".  Luckily I understand this by now and it actually works ok.  But it
does need fixing.

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

Re: [Talk-us] Mapping rail trails

2019-07-11 Thread 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

2019-06-24 Thread 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

2019-05-30 Thread 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: [OSM-talk] correct (scholarly) attribution?

2019-05-17 Thread Greg Troxel

Frederik Ramm  writes:

> Hi,
>
> if someone writes a scientific paper and wants to reference an OSM data
> set they used, what would be the correct way to do that? Typically such
> mentions contain author and name of the work, and publication place and
> year. Or maybe the web-like "retrieved on ..."?

I vote for not retrieved on but the date the data was extracted from the
main database, looking like "openstreetmap.org vector map data,
OpenStreetMap Contributors, extracted -MM-DD HHMM UTC".

My impression is that the publication date is for things where a journal
publishes them, and perhaps self-published blog posts, but for something
that is continuously modified, it doesn't really make sense.

It's also good to give a second citation to a journal article that gives
an overview the project, and surely that exists by now.  But I think the
most important thing is an unambiguous pointer to both OSM and the epoch
of data.

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

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

2019-05-09 Thread Greg Troxel

Michael Reichert  writes:

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

That seems like the right thing to do.

> - Uses don't get overwhelmed with dozens or hundreds of reports on
>   objects they did not touch.
>
> - If users follow suggestions how to fix blindly (we cannot expect an
>   unexperienced iD user to have the same knowledge as the average JOSM
>   user), they are used as living bots running validation rules on
>   randomly selected areas of the map. One might call this a hidden
>   automated edit.

It is very definitely an automated edit, and it is irresponsible to
deploy such a thing without going through the mechanical edit policy.

Obviouusly squaring all buildings would fail as a proposed mechanical
edit, because there is no basis to believe that this is almost always an
improvement.

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

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

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

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

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

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

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

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

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

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

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