Re: [Talk-us] Trouble with getting Superior National Forest

2020-09-04 Thread Doug Hembry

On Wed, Sep 2, 2020 at 7:34 PM brad  wrote:


I'm with Kevin, SteveA, etc,  here.   In the part of the world that I
live, a map without national forest & BLM boundaries is very incomplete.
A useful OSM needs this.   The useful boundary would be the actual
ownership boundary, not the outer potential ownership boundary.   Messy, I
know.


+1
In fact, true for all protected areas.

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


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

2018-06-12 Thread Doug Hembry
I stand with Greg Morgan and Rihards on this one (and I think, Steve, if 
I remember rightly). I watch my email, and read the messages and digests 
from the talk lists. I'm old-fashioned and don't even use a smart phone 
or any social media (probably the only person in California who 
doesn't). I'd noted what seemed to be a drop-off in talk-us messages, 
and wondered where everyone had gone, but I'm not signing up for Slack 
or any other apps just to keep in touch. If the talk-us community is 
migrating to Slack, then I'll just get used to being out of the loop. A 
pity, but I don't have time to change my habits, and like some other 
correspondents I have a gut suspicion of for-profit corporations.

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


Re: [Talk-us] Drop the tiger:reviewed tag from roads

2018-05-11 Thread Doug Hembry
One contrary view: I regret to say that there are still quite a few 
"tiger:reviewed=no" roads in my neck of the woods - the south San 
Francisco Bay area. I select the setting to highlight them in JOSM, and 
use it to remind myself to try to survey and fully tag them. Where 
possible I prefer to actually drive the road before removing the tag. 
Or, where impractical (like private roads), at least use imagery to 
adjust their alignment. If the tag wasn't there I'd pretty soon loose 
track of which roads needed attention.

So I cast a vote for keeping it. At least don't mechanically remove them 
all, everywhere.

- Doug

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


Re: [Talk-us] Parks, again

2018-01-07 Thread Doug Hembry
Thanks for the advice, Mateusz. I'll think about this some more, and if 
it still seems like a good idea I'll propose it on github. Andy Townsend 
gave me the same advice.

Best regards

- doug


On 1/7/2018 4:06 PM, Mateusz Konieczny wrote:
> For start: the best place to propose improvements to default map
> style is to propose it at
> https://github.com/gravitystorm/openstreetmap-carto
>
> In other places it is highly unusual that somebody involved in
> development map style will notice it and on issue tracker
> ( https://github.com/gravitystorm/openstreetmap-carto/issues ) proposed
> ideas stay under implementation or rejection so nothing is missed
> (though somebody still need to implement it),
>
>
> On Sun, 7 Jan 2018 19:58:54 +
> Doug Hembry <doughem...@hotmail.com> wrote:
>
>> You are right that I raised the issue of the green fill for
>> leisure=park because it is being used for large, wild protected
>> lands
> That is clearly incorrect tagging. But I guess that these people would
> just switch to leisure=pitch or leisure=garden if
> rendering for leisure=park would be removed.
>
>> I'm not sure what you meant about the national_park borders... I'm
>> sorry. Could you clarify?
> https://wiki.openstreetmap.org/wiki/Tag:boundary=national%20park?uselang=en
> is already rendered so I am curious why people still tag for renderer
> and use leisure=park in places that are something completely diffferent.
> Typically it stops when correct tagging is also displayed.
>
>> And it's really no big inconvenience for mappers to
>> add landuse=grass (or whatever) to their definition of a small urban
>> park.
> Note that in my experience (limited to Europe) it is very unusual for
> entire park to have a single land cover (either grass or trees or
> anything else) and it is vastly simpler to draw park area than many
> landcover=* or landuse=* areas.
>
>
>> On the other hand, one could argue that since the natural=*,
>> landcover=* (and even landuse=*) tags exist, why should we be
>> providing another, special way of fill-coloring parks (even small
>> urban parks)?
> Primarily - to display something useful also in areas that are not fully
> mapped (what is quite rare).
>
>> would be
>> to drop rendering for "boundary=national_park" and
>> "leisure=nature_reserve" as well
> I would not expect it to happen soon. Especially as this tagging is not
> terrible and is simpler than proposed new one and widely used.
>
> Completely broken waterway=wadi tag still haunts us (see
> https://github.com/gravitystorm/openstreetmap-carto/issues/1365 ) for
> links to gory details.
> .
>

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


Re: [Talk-us] Parks, again

2018-01-07 Thread Doug Hembry


On 1/7/2018 12:52 PM, Kevin Kenny wrote:
On Sun, Jan 7, 2018 at 2:58 PM, Doug Hembry 
<doughem...@hotmail.com<mailto:doughem...@hotmail.com>> wrote:
Briefly, my personal preference (for what it's worth), assuming
rendering is added at some point for "boundary=protected_area", would be
to drop rendering for "boundary=national_park" and
"leisure=nature_reserve" as well (as I'm suggesting for "leisure=park").
The "boundary=national_park" tag is redundant, given
"boundary=protected_area and protect_class=2 and
protection_title=national_park". IMHO, it could be deprecated. I don't
have an opinion on "leisure=nature_reserve". Maybe there's some value to
keeping it as part of the set of "leisure=*" values that describe
facilities for human recreation, but it doesn't need to explicitly render.

I have 'leisure=nature_reserve' on a lot of things so that they
will render with the renderer that we have.
+1 (or they use "boundary=national_park", then "boundary:type=protected_area" 
for the same reason)

I've been trying hard to make sure that they are
also tagged with 'boundary=protected_area protect_class=*
access=*' as well, so that when and if the renderer shifts
to protected areas, I'm good to go.

While posting this,
I discovered that I've missed a few, but I need to do
research to figure out what protect_class they are.
That's one reason that I don't like requiring that
'protect_class' be the only driver. It's often not observable
on the ground. I can't tag it correctly until and unless
I've done some non-field investigation.

+1  It seems probable that some people using the boundary=protected area set 
will initially skip the protect_class=* tag, or defer providing it, although 
the table in the wiki is useful. It will likely get filled in eventually by 
someone, and in the meantime, if/when the renderer supports these tags, it will 
probably have to tolerate a missing protect_class tag, maybe by assuming a 
default value (?)I've also done some limited landcover with a few areas
like https://www.openstreetmap.org/relation/6467468,
but I find it to be really slow going (getting it right involves
comparing summer and winter images, for instance).
In maps that I render, I ordinarily derive landcover
from non-OSM sources, so getting landcover for me
has a very low priority - I mostly map what I plan to
render. (Also called, "scratching your own itch.")
We're lucky in sunny CA, in that it's pretty clear from imagery where are the 
edges of woods, scrub or grasslands, etc. Season doesn't seem to cause 
problems. But around here, landcover that people have imported in the past 
tends to grossly inaccurate.

A fair number of 'national parks' are actually class 5 or 6, owing
to inholdings and private-public partnerships. They usually have
1b's and 2's embedded within them.

OK.. hadn't noticed this, but my point was that the protect_title tag documents 
that this is
a National Park.

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


[Talk-us] Parks, again.

2018-01-07 Thread Doug Hembry
On 01/07/2018 21:11, Andy Townsend wrote:

| To be honest, I wouldn't "suggest that OSM Carto do X" here - there's
| been a lot of discussion already and no conclusions there. What I'd
|suggest instead is that someone knocks up a rendering of California
| based on what it would look like if boundary=protected_area, or
| protect_class, or whatever is used instead of park, nature_reserve
| and/or national_park.  It's not that complicated to do that - there are
| basic instructions for creating a tile server at .

A good suggestion, Andy, but I think a bit beyond my skill level and 
time constraints.
However, I take your point that talk-us is not the place to bring up 
issues with OSM carto.
I may shut up about it on talk-us and look into how to raise the issue 
on github..

Cheers..
- doug

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


Re: [Talk-us] Parks, again

2018-01-07 Thread Doug Hembry
Hi Mateusz,
You are right that I raised the issue of the green fill for leisure=park 
because it is being used for large, wild protected lands, where it 
causes problems for "natural" and "landcover" tagging. If mappers only 
used it for smallish, low-protection, usually urban parks, as the wiki 
defines, it wouldn't be such a problem since these parks are usually 
mainly grass anyway, and no-one bothers to define them in detail with 
"natural=*" or "landcover=*".

So, yes, the problem arises in what I think is tagging for the renderer. 
And yes, that means it's really not the renderer's problem. Agreed..

On the other hand, one could argue that since the natural=*, landcover=* 
(and even landuse=*) tags exist, why should we be providing another, 
special way of fill-coloring parks (even small urban parks)? It would be 
more consistent to use the same set of landcover tags for ALL park-type 
and protected areas. And it's really no big inconvenience for mappers to 
add landuse=grass (or whatever) to their definition of a small urban 
park. (Incidentally, the other leisure=* areas that are provided with a 
fill-color (garden, playground, dog_park,..) are almost guaranteed to be 
small, and a single color fill is no problem)

I'm not sure what you meant about the national_park borders... I'm 
sorry. Could you clarify?

I stayed away from "boundary=national_park" and "leisure=nature_reserve" 
topic so as not to muddy the water in my original note. But I think it's 
true that there is also tagging for the renderer going on with these 
tags too - to force boundary rendering for "boundary=protected_area" 
which isn't there at present.

Briefly, my personal preference (for what it's worth), assuming 
rendering is added at some point for "boundary=protected_area", would be 
to drop rendering for "boundary=national_park" and 
"leisure=nature_reserve" as well (as I'm suggesting for "leisure=park"). 
The "boundary=national_park" tag is redundant, given 
"boundary=protected_area and protect_class=2 and 
protection_title=national_park". IMHO, it could be deprecated. I don't 
have an opinion on "leisure=nature_reserve". Maybe there's some value to 
keeping it as part of the set of "leisure=*" values that describe 
facilities for human recreation, but it doesn't need to explicitly render.

I should add that my comments are based only on experiences of my local 
neck of the woods (CA State, and maybe the west coast of the US). I know 
you have to consider requirements from all over..
Thanks for reading this far..


On 1/6/2018 7:58 PM, Mateusz Konieczny wrote:
> On Sat, 6 Jan 2018 21:11:04 +
> Doug Hembry <doughem...@hotmail.com> wrote:
>
>> IMHO, AT THE VERY LEAST, the background green fill for leisure=park
>> could and should be dropped by openstreeetmap-carto - it is
>> unnecessary, causes problems, and can be replaced by natural=* or
>> landcover=* . This would reduce one incentive for inappropriate use,
>> and if still used inappropriately, it wouldn't matter so much.
> I am not sure. As I understand, problem is caused by tagging for
> renderer - but national park borders are already displayed in this
> style.
> .
>

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


[Talk-us] Parks, again

2018-01-06 Thread Doug Hembry
Greetings everyone..

I have a stake in this discussion, being resident in CA and dealing 
regularly with the representation of the various state and local parks, 
Open Spaces, Ecological Reserves, water company lands, National Parks 
and Forests, etc, etc, with which this state is blessed. It's a crazy 
patchwork quilt of what are all, essentially, protected lands.

I'm broadly in agreement (I think) with Bradley White and other earlier 
posters and less so with Steve. My take is that "parks" differ 
essentially in their level of protection, and there is a whole spectrum 
of protection levels. These levels are already well described by the 
boundary=protected_area tag set. Protect_class encompasses a range from 
legally designated wilderness down to local urban parks (plus 
special-purpose areas). Protection_title=*, operator=*, and name=* 
capture information about the responsible jurisdiction (you can throw in 
"park_type" if you like, though it seems superfluous) and access=* 
(along with mapped trails, etc) describes the area's availability for 
public recreation. I don't think we need to embark on some big new 
program to determine how to map California's parks - we already have the 
means to do so. The boundary=protected_area might need some tweaking for 
national or local peculiarities and some discussion about what protect 
levels apply to what types of CA "parks", but it's already there and it 
works and we should just use it.

Protect_class is not just some abstract value of interest only to 
professional ecologists. The general "personality", and type of 
recreation available in a given park - ie, whether you take your dog and 
your kid in a stroller to picnic and play ball, or whether you carry 
survival equipment, bear spray, a PLB and GPS, or something in between - 
is strongly correlated  with level of protection. And given this, the 
importance of the leisure=park/nature_reserve tags for understanding 
"what kind of park is this?" is greatly decreased.

If I can throw in a note of cynicism: I have long suspected that there 
is a lot of deliberate tagging for the renderer going on in this whole 
business. I suspect the propensity for tagging anything with the word 
"Park" in it's name as leisure=park (given the wiki definition, 
seriously ?) stems from a belief by some mappers (no names) that the map 
is improved by fill-coloring all protected lands a light shade of green 
(It's gone so far that someone has been putting leisure=park on National 
Forests in Humboldt County). This is a terrible idea - apart from being 
totally counter to the wiki definition, the uniform green coloration of 
"parks" at medium to high zooms is incompatible with describing land 
cover characteristics with natural=* or landcover=*

IMHO, AT THE VERY LEAST, the background green fill for leisure=park 
could and should be dropped by openstreeetmap-carto - it is unnecessary, 
causes problems, and can be replaced by natural=* or landcover=* . This 
would reduce one incentive for inappropriate use, and if still used 
inappropriately, it wouldn't matter so much.

While on the topic of rendering "parks", I do agree with Steve (again, 
if I'm understanding correctly) that  it would be valuable, if possible 
at some point in the future - both for map clarity as well as providing 
useful information to users - for carto to use different colors for 
different types of boundaries. I differ with Steve in that IMO the 
coloring should be based off protect_class (or at least for several 
bands of protect_class if there are too many distinct values for 
separate colors) rather than jurisdiction. Jurisdiction is less 
meaningful to users than level of protection, and in any case is usually 
obvious from the area name and other tags. Further, boundary rendering 
should indicate access restrictions (access=yes/no/permit) by some means 
- perhaps a dashed line as is presently done for highways.

Happy New Year to all!

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


[Talk-us] Tagging outdoor US shopping centers

2014-12-23 Thread Doug Hembry
I'm a relative newbie, and here's a question I've been puzzling over for 
a while: What's the best practice for tagging a north American outdoor 
shopping center?  For example, often, on an intersection between major 
suburban streets, there are collections of stores, in one or multiple 
buildings, grouped around one or more shared car parks. And they have 
names (Cornerstone, Kings Court,... or whatever).  Sometimes there 
are four groups of stores, one on each quadrant of the intersection, 
with four different names. In the past, someone may have tagged the 
whole general area with landuse=retail (or landuse=commercial -  not 
sure why the difference),  but the map doesn't know of,  nor display,  
the distinct identities (which are frequently used locally in ads, etc). 
How to incorporate these distinct names, and if possible have mapnik 
display something? I have considered or seen several ways:


1.  Split a big generic landuse=retail area into multiple smaller 
landuse=retail  polygons, one for each shopping area. Then there are 
issues about whether adjacent areas should share boundary nodes with 
each other, or with separating roads. It gets complicated, and tedious 
to implement.


3. I've seen place=locality used on a single node with a name=*. It 
displays, but place=locality is supposed to describe an uninhabited 
region, according to the wiki.


4. Is this a legitimate use of the site relation? Buildings, shops, car 
park areas, gas stations, etc, could be grouped together and named, 
perhaps with a label tag, and no explicit boundary way required. The 
boundary of a shopping center is usually  fairly obvious when viewing 
the map - a drawn boundary might not be considered essential. This is 
attractive, but are site relations approved at this point, and will 
Mapnik display their names (I know... don't map for the renderer...)? 
Plus, I've never seen this used.


Breaking up a big landuse=retail area seems clumsy and problematic. And 
I suspect the usage of landuse=retail is supposed to be a generic, 
broad brush classification of a  whole region rather than a way of 
identifying smallish distinct contiguous areas, identical except for 
their names. What I think I need is a shop=shopping_center tag  (or 
shopping_centre, if our European colleagues insist :) ),  applied to 
either a strategically placed node or a newly defined boundary way. But 
it doesn't exist, strangely. Note that shop=mall isn't right, because 
malls are explicitly indoors. Maybe it's only here in California, where 
it never rains ( dark humor. At least until very recently) that we have 
this phenomenon of outdoor shoping areas, but I don't think so. Note 
also that single isolated shopping areas are not a problem - the 
landuse=retail area can simply be given a name=* tag.  But for the more 
complicated cases - any suggestions?


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