Re: [Talk-us] Trouble with getting Superior National Forest
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: [OSM-talk] OpenStreetMap Carto release v4.19.0
This is great news! "The Map" continues to get even better, and the protected_area rendering is especially welcome. Thanks to Daniel and the whole team! - Doug Hembry On 1/18/2019 3:59 AM, Daniel Koć wrote: > Dear all, > > Today, v4.19.0 of the OpenStreetMap Carto stylesheet (the default > stylesheet on the OSM website) has been released. Once changes are > deployed on the openstreetmap.org it will take couple of days before > all tiles show the new rendering. > > Changes include > - Adding rendering for boundary=protected_area (#3509) > - Nature reserve boundaries revision (#3574) > - Adding support of amenity=vending_machine (#3601) > - Adding more barrier icons (#3602) > - Changing allotments color and adding outline (#3625) > - Reducing priority of tourism=attraction and rendering from z17 (#3603) > - Changing tourism outline color (#3582) > - Making country borders thicker at z8 and z9 (#3563) > - Rendering parking from z14 (#3612) > - Starting to render most patterns at z13 instead of z14 (#3610) > - Changing zoom level and text size for place=hamlet (#3626) > - Rendering airport gate refs black instead of purple (#3620) > - Updating zoom levels by height for masts, towers and telescopes (#3536) > - Hiding underground parking (#3600) > - Rendering ref of minor roads more than once (#3627) > - Adjusting width of highway=construction (#3580) > - Selecting only motorway_link to tertiary_link as link (#3567) > - Reducing tertiary-link width (#3570) > - Changing certain amenity icons to grey (#3586) > - Converting springs to use ST_PointOnSurface and reformatting SQL (#3233) > - Adding "religious-icon" as color variable for #00 (#3642) > - Adding "barrier-icon" color variable in #3f3f3f for barriers (#3643) > - Fixing inconsistency of leisure=ice_rink (#3598) > - Fixing label opacity for tourism features (#3616) > - Reverting lowzoom nobuilding test change (#3622) > - Removing trailing whitespace (#3637) > > Thanks to all the contributors for this release. > > For a full list of commits, see > https://github.com/gravitystorm/openstreetmap-carto/compare/v4.18.0...v4.19.0 > > As always, we welcome any bug reports at > https://github.com/gravitystorm/openstreetmap-carto/issues > ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] anonymous notes spam?
Agreed. Now when I display these notes, the strange single-letter comments have disappeared. No idea what happened. On 7/20/2018 11:26 AM, Éric Gillet wrote: Same here. Le ven. 20 juil. 2018 à 20:25, Johnparis mailto:ok...@johnfreed.com>> a écrit : When I click on the samples I get full notes. Perhaps there was a database hiccup? On Fri, Jul 20, 2018, 18:29 Andrew Hain mailto:andrewhain...@hotmail.co.uk>> wrote: Can we find out what software is being used to send these notes? -- Andrew ____ From: Doug Hembry mailto:doughem...@hotmail.com>> Sent: 20 July 2018 14:26:13 To: talk@openstreetmap.org<mailto:talk@openstreetmap.org> Subject: Re: [OSM-talk] anonymous notes spam? Yes. In the San Francisco Bay Area. Single letters "f", "k", and "l". Example: https://www.openstreetmap.org/note/778721#map=15/37.5009/-122.3032=N BTW, is there a simple way to delete such note comments? On 7/20/2018 2:32 AM, maning sambale wrote: > I'm getting several single letter notes comments since yesterday. > Example: https://www.openstreetmap.org/note/562375 > Are people noticing the same? > ___ talk mailing list talk@openstreetmap.org<mailto:talk@openstreetmap.org> https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org<mailto:talk@openstreetmap.org> https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org<mailto:talk@openstreetmap.org> https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org<mailto:talk@openstreetmap.org> https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] anonymous notes spam?
Yes. In the San Francisco Bay Area. Single letters "f", "k", and "l". Example: https://www.openstreetmap.org/note/778721#map=15/37.5009/-122.3032=N BTW, is there a simple way to delete such note comments? On 7/20/2018 2:32 AM, maning sambale wrote: > I'm getting several single letter notes comments since yesterday. > Example: https://www.openstreetmap.org/note/562375 > Are people noticing the same? > ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-us] Slack: Do we need an Alternative (was Planning an import, in Price George...)
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
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
[Talk-ca] A new available source of trail data in the Nanaimo area
Greetings.. I wanted to bring to the attention of Vancouver Island mappers a source of some trail data in the Nanaimo area that I don't feel competent to handle myself. On a recent vacation visit to friends in Nanaimo, I learned that an association called the Back Country Horsemen of British Columbia have surveyed many of their customary riding trails around McKay Lake, resulting in a shapefile that they are prepared to make available to OSM. Originally, hearing about this shapefile, and expecting just a few trails clustered around the lake, I offered to import the data to OSM myself, but was surprised to find that it described quite a large network of trails covering a significant area. On reflection, given that I'm based in the SF Bay area in CA, and have zero local knowledge, I abandoned that idea. With the permission of my contact in the association, I'm asking if any local mappers might be interested in looking at the data with a view to importing it to OSM. The GPS survey appears to have been carefully done, and displayed in JOSM it conforms closely to those parts of the trails that are visible in imagery. The downside is that information describing physical characteristics (type of highway: path, track, road?; width, surface, smoothness, etc) is mostly absent. As is information about permissions (horse, bike, ATVs, private or public, etc), jurisdiction, and supporting amenities (eg, car parks, signage, water). Some of the trails do have names. So clearly some digging or surveying for the missing data would be necessary. (Possibly some association members might be willing to help, but I didn't bring up the possibility). But the point is, that this data describes real trails that are currently in use for equestrian recreation. And I believe (but am not certain) that the Trans-Canada trail (Great Trail?) intersects this trail network. So that's it... Anyone who is interested in looking into this source should feel free to contact Lynn deVries of Back Country Horsemen of BC at nese...@gmail.com<mailto:nese...@gmail.com> who can provide a copy of the shapefile. Best.. Doug Hembry ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-us] Parks, again
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
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.
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
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
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
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
