Re: [Tagging] Let's get (quite) rid of units and their multiples in OSM values
To avoid problems when querying, in case of explicitly add units, I would prefer to use a separate tag like maxspeed:units=mph, for example. Javier El sáb., 28 jul. 2018 10:30, Mark Wagner escribió: > On Fri, 27 Jul 2018 22:33:10 +0200 > François Lacombe wrote: > > > Well okay > > Given problem is how can we query maxspeed like : > > [Maxspeed>25] ? > > > > Which situation do we want to optimize for? The rare case, or the > common case? > > It's common to want to document legal restrictions such as "speed limit > 25 miles per hour", "no trucks over 2.5 meters tall", or "maximum > weight 3500 kilograms". It's rare to want to query ranges of speeds, > heights, or weights, particularly without regard to the units in use in > a given country. > > We should make it easy for people to enter and interpret these legal > restrictions, and if it means query software gets a bit more > complicated, so be it. For every person who wants to find roads > worldwide with speed limits greater than 25 km/h, there are probably > a thousand who don't want to deal with making sure the rounding is > correct when displaying US speed limits in miles per hour. > > -- > Mark > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] landuse=clearing
On Sun, Jul 29, 2018 at 12:57 AM, Graeme Fitzpatrick wrote: > > > The problem with that of course, as Warin mentioned, is what would it > hypothetically render as - grass / sand / rock / scrub etc etc? > If you simply define an area that is absent of woodland with no tags defining what it is, then it renders as an absence of woodland. It is a hole in the woodland that renders the same as whatever is outside the woodland, i.e., bare map. It's only if you add tags to the inner area that define it as grass/sand/whatever that it renders as anything other than "bare map." Or if there's a larger area enclosing the wood (such as a nature reserve) then the hole will (I haven't tested that, so make it "should" rather than "will") still render the same as outside the wood. I've poked holes in a wood to handle clearings, and poked holes in woods for ponds and quarries. It all works fine. If you don't trust me then give it a quick try. It's a matter of minutes to add a relation to the wood, transfer the tags from the wood to relation, then add one of the clearings to the relation and see what happens. If you hate the result then it's only a few more minutes to manually revert. It would be really nice if we had a sandbox, but we don't. In this particular case it's no big deal to give it a quick try. -- Paul ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] landuse=clearing
What I've tended to do with clearings is: o natural=wood for "here be trees", with leaf_type added. o If there's a large "landuse=forest" area already and that encompasses wood, clearings, ponds etc. (and there often is), leave that as "landuse=forest" or add as "landuse=forestry" (note - that tag is in very little use) o Add some kind of note for clearings, especially where trees have gone but are present on some imagery, and also some kind of note on tree areas that are newly planted and won't look like trees on imagery. This is all far from perfect, especially given all the other problems of mapping in trees (not all bits of woods accessible, imagery out of date, GPS traces miles off because of the trees, etc.). I wouldn't personally remove "invalid" landuse tags* unless I had a pretty good idea of what to replace them with (usually I'd need to have been there), and I'd certainly be wary of removing information that might be useful to future mappers, even if that information is only "this was mapped by an inexperienced HOT mapper using very odd tags a long time ago". Best Regards, Andy * genuine typos an obvious exception of course ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] landuse=clearing
On 29/07/18 20:37, Paul Allen wrote: On Sun, Jul 29, 2018 at 12:57 AM, Graeme Fitzpatrick mailto:graemefi...@gmail.com>> wrote: The problem with that of course, as Warin mentioned, is what would it hypothetically render as - grass / sand / rock / scrub etc etc? If you simply define an area that is absent of woodland with no tags defining what it is, then it renders as an absence of woodland. It is a hole in the woodland that renders the same as whatever is outside the woodland, i.e., bare map. It's only if you add tags to the inner area that define it as grass/sand/whatever that it renders as anything other than "bare map." Or if there's a larger area enclosing the wood (such as a nature reserve) then the hole will (I haven't tested that, so make it "should" rather than "will") still render the same as outside the wood. I've poked holes in a wood to handle clearings, and poked holes in woods for ponds and quarries. It all works fine. If you don't trust me then give it a quick try. It's a matter of minutes to add a relation to the wood, transfer the tags from the wood to relation, then add one of the clearings to the relation and see what happens. If you hate the result then it's only a few more minutes to manually revert. I too have created relations for tree areas and made 'holes' in them for various things. Some of those 'holes' may well be 'bare map'. The level of detail gained is proportional to the time taken, the resolution of the imagery and lack of cloud cover in the imagery. Fortunately there is now more than one good image source so clouds are less of a problem. The problem with the present data in this area is that; a) it does not render so 'we' don't know it is there by looking at the rendered map. b) it was done remotely using imagery .. so even the mapper did not know what really was there, other than a lack of trees at that time. c) HOT mapping may be speed driven, to get usefull data quickly to places in need, rather than good mapping. The problem is the presence of the tag 'landuse=clearing' that apparently, from both imagery and language, simply mean a lack of trees compared to the surrounding area. It is quicker to map these 'holes' as they are much less in length compared to the outer way. The 'landuse=clearing' says nothing about what is inside the area , other than the lack of trees, it could be dirt or grass or any other thing or things. To my mind that tagging can be replaced with these 'holes' in a tree relation as detailed above. OSM looses nothing by removing the tag provided the way is incorporated as an inner in a tree relation. If a mapper wants to look at an individual way .. then the history of that way is available, so they can see it came from landuse=clearing and who the original mapper was. I could add a tag - say a "comment=from HOT contribution, tagged landuse=clearing" .. that should suffice. In OSM 'we' try to tag what is on the ground, "landuse=clearing" to me means a lack of something - not what is there, but what is not there. And that is not something I'd even think about trying to render. Some time ago I tried to improve the mapping of the Kokoda Trail. That included the tree relation 7575948 https://www.openstreetmap.org/relation/7575948 That does show the 'holes' where what is there has not been mapped because it cannot be readily identified for aerial imagery. Note: The Kokoda Trail is mapped as a 'road'. No motor vehicle has ever been over it, other than in an aircraft. Even a bicycle would not be a good form of transport of it. In WW2 the Japanese did not take bicycles on it, one officer took a horse.. they killed it. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] landuse=clearing
On Sun, Jul 29, 2018 at 1:57 PM, Warin <61sundow...@gmail.com> wrote: I too have created relations for tree areas and made 'holes' in them for > various things. Some of those 'holes' may > well be 'bare map'. > [...] > The problem with the present data in this area is that; > > a) it does not render so 'we' don't know it is there by looking at the > rendered map. > That's the only problem. Your points b and c aren't problems (well, not the problem at immediate issue), they're the reasons why problem "a" exists. > I could add a tag - say a "comment=from HOT contribution, tagged > landuse=clearing" .. that should suffice. > You could do that. You could even retain the landuse=clearing tag, since it does no real harm, and comment that you've retained it in case it has local meaning that isn't documented on the wiki. Or you could do none of those things and just incorporate the area, with no tags, into a multipolygon on the basis that is clearly what was intended. If you wanted, you could also add a fixme stating that the nature of the clearing needs to be determined, so that people who look at validators might be tempted to go and look. > In OSM 'we' try to tag what is on the ground, "landuse=clearing" to me > means a lack of something - not what is there, but what is not there. And > that is not something I'd even think about trying to render. > Landuse=clearing in the middle of woodland means "not trees" and can be rendered by using a multipolygon to prevent trees rendering in that area. It would be nice to know what actually is there, but at least you can show that trees aren't there. A rambling diversion here, that will rejoin the main trail at the end. In the 1920s Alfred Korzybski came up with a self-improvement/therapy program he called "General Semantics" (nothing I say here should be taken as an endorsement of it). It had a key point to remind people that our knowledge and understanding of reality is only an approximation to reality: "The map is not the territory." OSM is only an approximation to the real world. I try to improve that approximation, where possible. Sea everywhere is an approximation. An island in the sea is a better approximation. Adding woodland to the island is a better approximation than that. Poking a hole in the woodland is an even better approximation. Tagging what that clearing is (scrub/grass/rock/whatever) is an even better approximation. I don't let the fact that I can't achieve perfection stop me from improving what is there. I'd have changed that landuse=clearing to an inner in a multipolygon without bothering to say anything here. If the imagery had contradicted the tagging, I'd have left it alone, but if the imagery shows "not trees" then map "not trees." -- Paul ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Missing access value (access=license / authorization?)
2018.07.27. 23:47 keltezéssel, Kevin Kenny írta: On Fri, Jul 27, 2018 at 11:54 AM marc marc wrote: a good idea would be to explain with a (as easy as possible) example why access=customers or private does not fit for your need. If it was what you did in your previous email, sorry but I didn't understand it, because your examples are too general, without explanation about existing tag problems (Side note: I favour 'access=permit' over 'access=licence' because it's spelt the same way on both sides of the Atlantic. Choosing a tag that's spelt differently in US and UK English simply invites misspellings.) Here's an attempt at an explanation: In the area that I'm mapping, there are rural regions - even with the same land management - that have different regulatory regimes - and I wish to render them differently. They fall into major categories. I'll also include specific examples from the New York City water supply lands, because that specific land owner has (or has had) examples in all the categories. [1] 'access=private'. These are private lands, or government-owned lands for which public access is not routinely granted. They are usually posted 'NO TRESPASSING' or similar verbiage - but would also comprise farmers' fields and the curtilage of private houses. For these, unless I have a relationship with the landowner, I have no reason to expect access, and it would be regarded socially as being quite strange to request it without a compelling reason. On a hiking map, I'd show these as 'out of bounds - off limits'. The New York City water supply bureau owns large parcels of land in this category - marked with uniform yellow NO TRESPASSING signs. that look like http://www.nyc.gov/html/dep/images/resources/watershed_sign4.jpg . I cannot show an OSM example because I haven't mapped them in OSM. I don't map that sort of cadastre; instead, for lands, I consider 'access=private' to be the default. Summary: "Ordinarily, no access to the general public" [2] 'access=customers'. There are a number of clubs, resorts, ski areas, and similar facilities that sell access (often labeled something like a 'grounds membership' - offering the right to cross the lands but none of the other club services). There is a reason that I might be authorized as a member of the general public. (Of course, 'customers' may also include guests of members, conference attendees at resorts, and similar prople.) Some government-owned lands fall under this category - for instance, there are government watershed-protection lands that ordinarily offer public access only in hunting season to hunters who've paid for the privilege. The New York City lands under this scheme are marked with special-purpose signs like http://www.nyc.gov/html/dep/images/resources/watershed_sign5.jpg . These signs differ from area to area, since so do the ways of obtaining the privilege to use the land. I do see this as an actual business-customer relationship (with the government as the business). One such area is https://www.openstreetmap.org/way/422887495. It's not tagged 'access=customers' at present, but I'd have no objection to making the change. Summary: "Access only to transact with the public-facing business that occupies the land" [3] 'access=permissive'. This more often applies to ways than lands, but it there's no reason it couldn't apply to either. Often, a landowner will retain control of access but offers the general public revocable rights to cross the land, usually in a specific corridor. There will ordinarily be the indicia of a hiking trail, and frequently there will be NO TRESPASSING signs on either side of the trail. Often, there will be standing rules; for instance, one trail that I access has a standing closure from October 15-December 31 of each year, plus occasional closures when members of the family that owns the land are hosting large gatherings. There are several trails that cross otherwise-posted New York City watershed lands. One example is https://www.openstreetmap.org/way/285951320#map=15/42.0850/-74.2496, which is on such lands between the end of the pavement on Jessup Road until it starts following the boundary of the Mount Tobias wild forest. In the field, there are NO TRESPASSING signs on both sides of the trail corridor from Jessup Road to the property corner, and then NO TRESPASSING signs on the northeast side up to the junction with the trails to Warner Creek and to Phoenicia. I've also been in there and found that permission had been revoked temporarily, with signage that looked like http://www.nyc.gov/html/dep/images/graphics/active-forestry-management-proejct.png. (The workers were friendly, and conducted my party through the closure.) I concede that the 'highway=footway' there may need 'foot=permissive', but I'm not going to trouble to retag unless I happen to find out whether a permanent easement exists for the trail. (If there's a deeded easement, then of course it's 'access=yes' and the closure was akin to
Re: [Tagging] Missing access value (access=license / authorization?)
sent from a phone > On 27. Jul 2018, at 17:53, marc marc wrote: > > what _I_ was saying is that despite your detailed explanations, > i still have not understood how the case you describe is different from > access=customers. some paths in the park of a castle are limited to the > customer of the castle, some sports facilities are limited to members > of the sports club. In the case of a castle which requires to pay an admission fee, I would certainly not call the visitors “customers of the castle”. Similarly, the members of a sports club are not “customers”. I would not add access restrictions to the castle but add a fee tag, and for the sports club I would use “private”. the fact of having to pay or not, is indicated > > by the key fee=* +1 cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Missing access value (access=license / authorization?)
sent from a phone > On 27. Jul 2018, at 17:53, marc marc wrote: > > I didn't understand how getting a license in your example is different > from getting a license from a sports club. I would understand that the permit will be obtained by everybody following the application rules, while the sports club doesn’t give you a “license”, it requires you to be a member, where it is usually at the discretion of the other members if they take you or not. Ciao, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Missing access value (access=license / authorization?)
Le 29. 07. 18 à 22:35, Martin Koppenhoefer a écrit : >> On 27. Jul 2018, at 17:53, marc marc wrote: >> I didn't understand how getting a license in your example is different >> from getting a license from a sports club. > I would understand that the permit will be obtained by everybody following > the application rules, while the sports club doesn’t give you a “license”, it > requires you to be a member, where it is usually at the discretion of the > other members if they take you or not. maybe for a golf sport club. but for all other sport club I have or I had be a member, no other members have to (dis)agree or not. I only need to fill a form, follow the rule and sometime pay a fee So I now understand that what somebody call a permit is a license for somebody else :) > I would certainly not call the visitors “customers of the castle”. > Similarly, the members of a sports club are not “customers” so who are the customers of a POI ? how to map a "for customers only" ? I often see this tagged as "access=customers" ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Let's get (quite) rid of units and their multiples in OSM values
sent from a phone > On 27. Jul 2018, at 19:48, Kevin Kenny wrote: > > I'm all for SI units for things like voltages and elevations. I'm > perfectly fine with tagging the elevation of Slide Mountain as 1274 > metres and letting a US data consumer convert that to 4180 feet. > > Regulatory things like maxspeed=* should have the unit in the tag, and > they should be in the same units that the signs are in. A sign reading > 'Speed limit 25 mph' means 25 mph, and entering 40.2336 km/h loses the > information that the regulatory signs are in US customary units. +1. In the case of elevation data, even if someone writes in the wiki that using SI units is mandatory, and elevations should be with respect to the EGM96 sea level, you should still expect there will be many mappers copying numbers from a sign without any conversion. And it could even make more sense to display the elevation in the locally common system, i.e. what is on the sign would also be on the (local) map. I agree this could on the other hand be seen as inconsistent, but I guess it is what is already happening. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Let's get (quite) rid of units and their multiples in OSM values
sent from a phone > On 29. Jul 2018, at 09:57, Javier Sánchez Portero > wrote: > > To avoid problems when querying, in case of explicitly add units, I would > prefer to use a separate tag like maxspeed:units=mph, for example. spreading the information over 2 tags creates another point of possible failure: units and tag value getting out of sync. Moving the unit into the key would work better in some way: height_m=3 maxspeed_mph=25 It would enable differing values in different units, but at least these would be evidently wrong (e.g maxspeed_kph=30 and ...mph=25 on the same object), and of course you shouldn’t add both anyway (unless they would both be legally correct) cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] landuse=clearing
sent from a phone > On 29. Jul 2018, at 14:57, Warin <61sundow...@gmail.com> wrote: > > It is quicker to map these 'holes' as they are much less in length compared > to the outer way. > The 'landuse=clearing' says nothing about what is inside the area , other > than the lack of trees, it could be dirt or grass or any other thing or > things. > To my mind that tagging can be replaced with these 'holes' in a tree relation > as detailed above. > OSM looses nothing by removing the tag provided the way is incorporated as an > inner in a tree relation I support this Cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Let's get (quite) rid of units and their multiples in OSM values
That sounds right but would not be clearer to use spacename instead of underscore? Like maxspeed:mph=25 That way you have to deal with main keys instead of split them into one key per unit. El lun., 30 jul. 2018 0:22, Martin Koppenhoefer escribió: > > > sent from a phone > > > On 29. Jul 2018, at 09:57, Javier Sánchez Portero > wrote: > > > > To avoid problems when querying, in case of explicitly add units, I > would prefer to use a separate tag like maxspeed:units=mph, for example. > > > spreading the information over 2 tags creates another point of possible > failure: units and tag value getting out of sync. > > Moving the unit into the key would work better in some way: height_m=3 > maxspeed_mph=25 > It would enable differing values in different units, but at least these > would be evidently wrong (e.g maxspeed_kph=30 and ...mph=25 on the same > object), and of course you shouldn’t add both anyway (unless they would > both be legally correct) > > cheers, > Martin > > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
