Re: [Tagging] Feature Proposal – RFC – natural=peninsula (Was: Feature Proposal – RFC – place=peninsula)
When I look at the area, it turns out that Pointe des Espagnols is the extreme tip of the Roscanvel Peninsula, which itself comes off the Crozon Peninsula eg https://upload.wikimedia.org/wikipedia/commons/6/65/Iroise_sea_map-en.svg If we add say Pointe des Capucins & Point de Cornouaille, it would all be a perfect example of the " > OK, how about "A natural=cape can be part of a natural=peninsula, a natural=peninsula can be part of a larger natural=peninsula, but a natural=peninsula cannot be part of a natural=cape"? Or: 'A natural=cape can be part of a natural=peninsula, but a natural=peninsula cannot be part of a natural=cape. However, a natural=peninsula can be part of a larger natural=peninsula.'?" description! Thanks Graeme On Tue, 22 Jan 2019 at 09:13, Christoph Hormann wrote: > this might still be read as there being > necessarily a 1:1 relationship between a natural=cape and a > natural=peninsula (and your illustration therefore showing Pointe des > Espagnols but not Pointe des Capucins). > > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal – RFC – natural=peninsula (Was: Feature Proposal – RFC – place=peninsula)
On Monday 21 January 2019, Markus wrote: > > I've improved the differentiation from natural=cape and abandoned the > minimal area requirement of 1 km². Please tell me if it makes sense > now. That looks better though this might still be read as there being necessarily a 1:1 relationship between a natural=cape and a natural=peninsula (and your illustration therefore showing Pointe des Espagnols but not Pointe des Capucins). -- Christoph Hormann http://www.imagico.de/ ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] The actual use of the level tag
On 21.01.19 22:38, Roland Olbricht wrote: > I do consider both to be SIT compliant. I'm not sure if it's clear from the written text of SIT, but neither fractional levels nor indoor features outside of a building outline were part of SIT's design. (And yes, these are obvious omissions that will need work.) > In particular, there is no object that could or should carry tags > applying to all involved objects. Levels only have meaning within a single structure, though. Level "2" in the neighbouring building (or even building part) might represent an entirely different absolute elevation. An important assumption (and limitation, because this isn't always true in reality) of SIT is, therefore, that there is some kind of outline within which a level number refers to a single, fixed elevation. I didn't really raise that point so far because I don't have a better solution to offer yet, but your station mapping does contradict the assumptions we had when writing SIT, and I feel we should collaborate to define the semantics of such a situation. > But I do not see yet why there should be a mapping of levels to integers > at all. One reason that's of particular interest to me is that SIT is intended to be compatible with 3D rendering, allowing for the creation of 3D models that represent both the inside and outside of buildings at the same time. At the moment, Simple 3D Buildings has no support for "half" levels, so if we want to preserve that feature of SIT, we would need to update both tagging standards at the same time. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal – RFC – natural=peninsula (Was: Feature Proposal – RFC – place=peninsula)
On Sat, 19 Jan 2019 at 23:00, Christoph Hormann wrote: > > > A piece of land that projects into a body of water. > > Sounds like a peninsula to me. Nearly the same definition is used for natural=cape: 'A piece of elevated land sticking out into the sea or large lake.' This is the reason why i got confused. I've improved the differentiation from natural=cape and abandoned the minimal area requirement of 1 km². Please tell me if it makes sense now. Regards Markus ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] The actual use of the level tag
Hi Tobias, thank you for keeping the discussion. One extra thing I have just learned is that non-numerical level refs are not-so-uncommon in the US, hence should be covered by a tool to be helpful there. > I do not want to sound so combative or negative here - to reason > for why a new tag may be useful, I just need to describe the problem. > I want us all to be on the same page. I am still not yet sure about where we are starting from and where we are going to. Typical examples would be for me: https://openlevelup.net/?l=-2#20/55.68178/12.55260 https://openlevelup.net/?l=-0.5#18/51.23423/6.77858 I do consider both to be SIT compliant. In both cases there is no building outline (at least no canonical one; footprint on the street level is different from the total of passenger visible area is different from the area covered by concrete foundations and so on). In particular, there is no object that could or should carry tags applying to all involved objects. Given that one often cannot even decide for a station complex whether it is one or multiple stations, there often cannot be a global object responsible for the structure as a whole. The half numbered levels for the small mezzanines fit intuitively into the whole level order -2, -1, 0 as signposted by the operator. Thus there also is no need for an explicitly declared order on a global object. There is an obvious order of the levels there by reading them as fractional numbers. And all tools I am aware of (OpenLevelUp, JOSM, OpenStationMap and others) can work with this sequence of levels. So I do support to have new extra tags that keeps whatever important but yet missing information. But I do not see yet why there should be a mapping of levels to integers at all. Clarifying this point probably would help to understand whether there is a preferred choice for 0, whether missing levels need to be modeled at all and what to do with small mezzanines: Shall they trigger to have a gap for them in a potentially large building complex? Can disjoint mezzanines between larger levels get the same level designation to keep the index dense? Best regards, Roland ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Forest parcel with other landcover (scrub, scree…): how to map?
On Mon, 21 Jan 2019 at 20:21, Warin <61sundow...@gmail.com> wrote: > > My problem with going to landuse=forestry with natural=wood... > > what happens to the remaining landuse=forest? > Will that finally be recognised as the same as natural=wood and be > migrated to natural=wood??? > Ideally, if we get landuse=forestry and it eventually renders, landuse=forest would be deprecated and slowly replaced when a mapper encounters it. It's a misbegotten tag that has been used inconsistently. It was intended to mean what the suggested landuse=forestry means, but has largely been used to mean what natural=wood means. landuse=forest is wrong two ways. A forest is not landuse. You might be able to justify landcover=forest but that's already dealt with by landcover=trees. You might be able to make an argument for natural=forest (a big wood) in the same way we draw a distinction between rivers and streams. The only way it can be considered landuse is if the land is used for forestry, but then we have the mismatch with natural English which is part of the reason it was misused and part of the reason people keep proposing landuse=forestry. Any migration would have to be on a case-by-case basis. If land used for forestry is tagged as landuse=forest it should (eventually) be migrated to landuse=forestry. If not used for forestry then landcover=trees or natural=wood. But all that requires that this list and the carto people manage to get all our shit in the same sock. Maybe it's worth a formal proposal for landuse=forestry suggesting dual-tagging as an interim workaround for it not being rendered, with a later clean-up. Because we're going to keep coming back to this one until we finally do something about it. -- Paul ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Forest parcel with other landcover (scrub, scree…): how to map?
On 22/01/19 04:29, Kevin Kenny wrote: On Mon, Jan 21, 2019 at 7:45 AM Paul Allen wrote: What if we suggest in the wiki that where trees are used for actual forestry people are encouraged to dual-tag with landuse=forestry + natural=wood on the basis that with enough usage the carto group will render landuse=forestry AND that when they do there will be an effort to remove natural=wood when it appears in combination with landuse=forestry. What was I thinking? That might actually get us somewhere, and we wouldn't want to do that. Your post was dead on target, right up to here - and the dual-tagging suggestion is a good one. I do that a lot - precise tagging that doesn't render combined with imprecise tagging 'for the renderer'. By this I do not mean tagging falsehoods because they render nicely, which is unacceptable, but rather tagging features like 'leisure=nature_reserve', which covers anything from the vacant lot that the city has set aside for birds to the vast tracts of a national forest. I can try to be accurate with protect_class and the like while not sacrificing the ability to have the tagged feature show up on maps. Nevertheless, even if all the intended tags render correctly, there's nothing wrong with tagging both land USE and land COVER - which are two different things. One is human and social - "to what use are people putting this land?" "They're growing trees on it." It is more than just growing. The growing thing has to produce something for human benefit, usually some form of harvesting to provide a produce. Grass can be grown to produce turf. Trees can be grown to produce timber. If there is no human benefit from the plant growth then the landuse cannot be the plant. The area may not have any 'land use' (i.e. a wasteland) or it may be used for conservation, but it is not related to the plant. The other is physical, "if I look down on this land from above, what will I see?" "It's a beaver pond in the middle of a forest." A landuse=forest[ry] will surely be largely natural=wood and/or landcover=trees. But forestry is a long game. Near me there are state forests that are unquestionably managed for production (with public recreation a secondary goal), that are mostly 'trees', but some 'grass' or 'scrub' (recently acquired parcels, or recently logged ones), and even some water and wetland (thank you, beavers!). The fact that an area is a beaver pond today doesn't mean that it won't progress through marsh, scrub, laurel meadow, alder thicket, and so on to forest over the years - and the land is managed for the long haul, in the expectation of such a succession. Forestry is the land USE - the land COVER varies. Both are important. Putting landcover=trees or natural=wood on the pond is wrong. There's no wood there. Putting landuse=forest[ry] on the pond may be right. When the beavers move away, that land will be productive again . In fact, it will likely be more productive than before they arrived. There's pretty solid evidence that beavers improve the forest over time. Some forestry operations used to use rivers to transport the timber down stream to a lake. --- My problem with going to landuse=forestry with natural=wood... what happens to the remaining landuse=forest? Will that finally be recognised as the same as natural=wood and be migrated to natural=wood??? ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] The actual use of the level tag
On 21/01/2019 09:19, PanierAvide wrote: > Just for your information, there is also this "level:ref" tag which was > used in various context to solve this problem I know of "level:ref". However, on the SIT wiki page, "level:ref" is documented as a tag for the level-outline tagged with "indoor=level", not as an alternative to "level" on each individual shop. So, it is possible to make the connection between the index and the level denomination, but it is not exactly straightforward. I just wrote a longer description (of the problem) on another branch: https://lists.openstreetmap.org/pipermail/tagging/2019-January/042369.html Regards Tobias ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] The actual use of the level tag
On 20/01/2019 23:39, Tobias Knerr wrote:
> The main challenge I see with your proposal, though, is that the
> levels=* tag on the building would be utterly required to make any sense
> of the order of floors. Without it, applications would have no idea
> whether "M" is above or below "P2", for example. So at the very least,
> adding levels=* should explicitly be documented as mandatory when using
> non-standard levels.
Yes, the levels=* would be mandatory for proper ordering in those cases
where the floor levels are not numerical. For places where it is
numerical, nothing changes. It'd be an extension after all.
Consider: For places where they are not numerical, only
levels="LG,UG,M,1,2" on the building (part) outline is required to allow
tagging shops with a non-numerical level, nothing more.
In the current SIT scheme*, in this case, it is required to add 5
additional outlines, one for each floor (indoor=level), and tag each
with a level-index (level) and floor denomination (level:ref) in order
to create the relation between the level-indices as tagged on each
individual shop and the actual floor denomination.
In other words, to map a mall with non-numerical floor numbers already
requires to use the stuff described under "advanced modelling", and it
is more than one tag, it is 5 times "level" and 5 times "level:ref".
Additionally, one has to tag each shop not with the actual floor
denomination, but with the said level-index referenced in each floor
outline.
In the described case of non-numerical floors, the level-index becomes a
purely virtual ("programmer's") value which only becomes meaningful when
all the data is put together. And apart from making the machine
understand the relation between index and ref, the mapper himself needs
to make the conversion (in his head - .oO("UG is 0", "M is 1", "1 is
2",...)) for every shop he maps as well, which is prone to error,
especially with sporadic contributors.
In a nutshell, mappers and software are expected to know and use the
(advanced) SIT scheme if they "just" want to map on which floor a shop
is located.
I do not want to sound so combative or negative here - to reason for why
a new tag may be useful, I just need to describe the problem. I want us
all to be on the same page.
* as far as I understand it, correct me if I am wrong
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Forest parcel with other landcover (scrub, scree…): how to map?
On Mon, Jan 21, 2019 at 7:45 AM Paul Allen wrote: > What if we suggest in the wiki that where trees are used for actual forestry > people are > encouraged to dual-tag with landuse=forestry + natural=wood on the basis that > with > enough usage the carto group will render landuse=forestry AND that when they > do there > will be an effort to remove natural=wood when it appears in combination with > landuse=forestry. What was I thinking? That might actually get us > somewhere, and we > wouldn't want to do that. Your post was dead on target, right up to here - and the dual-tagging suggestion is a good one. I do that a lot - precise tagging that doesn't render combined with imprecise tagging 'for the renderer'. By this I do not mean tagging falsehoods because they render nicely, which is unacceptable, but rather tagging features like 'leisure=nature_reserve', which covers anything from the vacant lot that the city has set aside for birds to the vast tracts of a national forest. I can try to be accurate with protect_class and the like while not sacrificing the ability to have the tagged feature show up on maps. Nevertheless, even if all the intended tags render correctly, there's nothing wrong with tagging both land USE and land COVER - which are two different things. One is human and social - "to what use are people putting this land?" "They're growing trees on it." The other is physical, "if I look down on this land from above, what will I see?" "It's a beaver pond in the middle of a forest." A landuse=forest[ry] will surely be largely natural=wood and/or landcover=trees. But forestry is a long game. Near me there are state forests that are unquestionably managed for production (with public recreation a secondary goal), that are mostly 'trees', but some 'grass' or 'scrub' (recently acquired parcels, or recently logged ones), and even some water and wetland (thank you, beavers!). The fact that an area is a beaver pond today doesn't mean that it won't progress through marsh, scrub, laurel meadow, alder thicket, and so on to forest over the years - and the land is managed for the long haul, in the expectation of such a succession. Forestry is the land USE - the land COVER varies. Both are important. Putting landcover=trees or natural=wood on the pond is wrong. There's no wood there. Putting landuse=forest[ry] on the pond may be right. When the beavers move away, that land will be productive again . In fact, it will likely be more productive than before they arrived. There's pretty solid evidence that beavers improve the forest over time. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Forest parcel with other landcover (scrub, scree…): how to map?
On Mon, Jan 21, 2019 at 12:45 PM Paul Allen wrote: > Around and around we go. This list cannot agree on approving > landuse=forestry because it > doesn't get rendered. The carto people refuse to render landuse=forestry > because nobody > uses it. Sometimes the semi-anarchic nature of OSM tagging can be very > frustrating. There > are days when I yearn for joined-up thinking. > > How about... I expect it will get shouted down for many reasons, but... > > What if we suggest in the wiki that where trees are used for actual > forestry people are > encouraged to dual-tag with landuse=forestry + natural=wood on the basis > that with > enough usage the carto group will render landuse=forestry AND that when > they do there > will be an effort to remove natural=wood when it appears in combination > with > landuse=forestry. What was I thinking? That might actually get us > somewhere, and we > wouldn't want to do that. > I tend to share the same sentiment as yourself regarding this seemingly endless back and forth between rendering and tagging. It clearly indicates where change would be beneficial and a join system could be established by both to move things forward (similar to how there's a clear system for tag proposals, it might not be perfect, but it promotes progress). As for your suggestion, this is already my approach for "landuse=grass" and "landcover=grass". Tag both, hope that one day the old confusing tag has less isolated usage than the combination and someone realises we can remove the old one from all combined cases. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Forest parcel with other landcover (scrub, scree…): how to map?
On Mon, 21 Jan 2019 at 04:20, Andy Townsend wrote: One suggestion that I've made here before is explicitly to use > "landuse=forestry" for areas that may or may not have trees on them, if > the areas with trees within have been mapped separately > You're not the only one to have made that suggestion. It makes a lot of sense, since the original intent for landuse=forest was for forestry and the natural language/OSM mismatch is one reason the tag is often used for a different purpose than intended. I've mapped several areas of trees where the OS_OpenData_StreetView layer shows a different extent than is visible in aerial imagery. - sometimes a lesser extent, sometimes a greater extent. And in some of those cases where the OS layer is larger than visible in aerial imagery, the aerial imagery shows a fence matching up with the OS layer AND what appears to be tree stumps or scrub or young trees or whatever where the two views disagree. If I map the visible extent of the trees, years from now somebody will have to change the outline to match new growth. If I include tree stumps then somebody might change the outline the next day to match what is visible. Having landuse=forestry that really does mean forestry (as opposed to landuse=forest that was intended to mean forestry but rarely does) would deal with some of the issues. It would be up to the mapper to decide whether it's worth the hassle of using landcover=trees to show the current extent of trees. [...] > That renderer also processes landuse=forest the same way - see > https://www.openstreetmap.org/way/44018882 and > > https://map.atownsend.org.uk/maps/map/map.html#zoom=15=53.21319=-1.18217 > for an example of that. > And there's the rub. The standard carto ignores landuse=forestry. Which means that people end up tagging for the renderer by using landuse=forest or natural=wood. Because woodland is tedious to map and there's no point going to all that effort if it's not going to render. It's unrealistic to expect most mappers to use landuse=forestry unless it renders. Around and around we go. This list cannot agree on approving landuse=forestry because it doesn't get rendered. The carto people refuse to render landuse=forestry because nobody uses it. Sometimes the semi-anarchic nature of OSM tagging can be very frustrating. There are days when I yearn for joined-up thinking. How about... I expect it will get shouted down for many reasons, but... What if we suggest in the wiki that where trees are used for actual forestry people are encouraged to dual-tag with landuse=forestry + natural=wood on the basis that with enough usage the carto group will render landuse=forestry AND that when they do there will be an effort to remove natural=wood when it appears in combination with landuse=forestry. What was I thinking? That might actually get us somewhere, and we wouldn't want to do that. -- Paul ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] The actual use of the level tag
Yes it makes sense to keep this distinction : level tag can just be the "logical order" of levels going from -xx to xx with an arbitrary 0 for each building, so tools know the order (which one is above the other). Simple Indoor Tagging already suggest the level:ref for the "local" naming scheme. It could be used by tools when they show you the name of the level in their interface (One example : a building with tags "level=0" + "level:ref=Ground floor", instead of showing "level 0", the tool can display "Ground floor" -> both the data user and the data consumers are happy ;-) ). Le lun. 21 janv. 2019 à 09:20, PanierAvide a écrit : > Hello, > > Just for your information, there is also this "level:ref" tag which was > used in various context to solve this problem : > > - level tag is still used as defined in Simple Indoor Tagging > - level:ref has a value which is linked to operator naming of levels > > That way, casual mappers/consumers don't need to stick to level definition > which doesn't make regarding operator naming, they can set level:ref > according to what they are used to see. And we keep the level definition > which makes more sense for tools. > > Regards, > > Adrien. > > PanierAvide > Géomaticien et développeur > > Le 21/01/2019 à 09:05, Simon Poole a écrit : > > As tordanik has already pointed out the main issue with the proposals is > that there is no inherent ordering that can be deduced from level values > on objects if they are not (integer) numbers, so any such scheme > requires far more insight, effort and available context from > joe-casual-mapper and joe-casual-data-consumer to get layering right. > With the current scheme that is a no-brainer even if there are > discrepancies between actual numbering of the floors and what is being > used in OSM. > > Simon > > PS: addr tags are for postal addresses I don't think using them as a > level name/ref makes very much sense outside of that very narrow > application. > > > > > ___ > Tagging mailing > listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging > > ___ > 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] The actual use of the level tag
Am So., 20. Jan. 2019 um 23:41 Uhr schrieb Tobias Knerr : > On 20.01.19 19:37, Tobias Zwick wrote: > > - a shop on level M with "level=M" > > > > - the mall building with "levels=P2,P1,G,M,1-12,14-99" (the order of the > > levels). If levels is missing, a numerical order is assumed > > So essentially, one uses the local level reference in level=*, and > provides a mapping onto a standardized level sequence with separate, > building-wide tags. > +0.95 The mapping should relate to the most useful unit (the one which is locally used), this can be the building, but it can also be a building:part. Sometimes, numbering follows building parts, not the "global" building. Cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] The actual use of the level tag
Am So., 20. Jan. 2019 um 18:07 Uhr schrieb Roland Olbricht < roland.olbri...@gmx.de>: > we have here in Wuppertal, Germany at least three indoor-tagged > structures that have street level entrances at multiple levels, making > "street level" a not-at-all defined concept. +1, also from my experience, entrances on different levels are typical for big structures without a single centralized entrance, like shopping malls usually are. Different street levels are used to reduce congestions. I would see the level as indicated locally (on the ground) the most useful thing to know. This can also deal with things like level B1, B2 for intermediate levels of smaller buildings parts and similar. Huge structures sometimes use levels 0, 1, 2, 3, 4, ... for the "main levels" (sometimes with significant bigger vertical floor distances than the 3-4 m that are the minimum) but also have numbering for intermediate levels. Cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] RfC - tagging whatever power line is isolated as attribute
In the proposal there is a statement: " it is impossible to check whatever power line is insulated during survey without closely approaching power line" I thought, that the distinction is very easy; insulated cables don't need insulated suspension. Insulated suspension is very easy to see. Or am I wrong? On Sat, 3 Nov 2018 at 22:31, Warin <61sundow...@gmail.com> wrote: > On 04/11/18 06:45, Paul Allen wrote: > > On Sat, Nov 3, 2018 at 7:34 PM Mateusz Konieczny > wrote: > >> Thanks! It was intended to be about insulation. >> > > It now makes a lot more sense. However, the word "isolated" is present > twice in the rationale. > > You probably ought to mention something that was brought up on this list: > that some power > lines have a cladding which is not considered to be an electrical > insulator. It is unlikely most > mappers could tell the difference. > > Yes, there are insulated cables. They're present on minor power lines for > local distribution (they > run along streets with feeds to houses along the street) near me. At some > points the line > between poles is a single insulated cable and at other points along the > same street it switches > to four, physically-separated, uninsulated conductors. It appears to me > that the uninsulated > stretches are older than the insulated ones and that as repairs become > necessary they change > to insulated cable. I suspect that on anything other than this type of > local distribution any covering > around the wire is cladding rather than insulation. > > > This may be true for local low voltage distribution in your area. > > In my residential area low voltage distribution runs insulated from the > power pole to the residences, but uninsulated from power pole to power > pole. > > - > High voltage (10s if not 100s of kilo volts) run uninsulated here and I'd > think that would be true anywhere. > > > > > > ___ > 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] The actual use of the level tag
Hello, Just for your information, there is also this "level:ref" tag which was used in various context to solve this problem : - level tag is still used as defined in Simple Indoor Tagging - level:ref has a value which is linked to operator naming of levels That way, casual mappers/consumers don't need to stick to level definition which doesn't make regarding operator naming, they can set level:ref according to what they are used to see. And we keep the level definition which makes more sense for tools. Regards, Adrien. PanierAvide Géomaticien et développeur Le 21/01/2019 à 09:05, Simon Poole a écrit : As tordanik has already pointed out the main issue with the proposals is that there is no inherent ordering that can be deduced from level values on objects if they are not (integer) numbers, so any such scheme requires far more insight, effort and available context from joe-casual-mapper and joe-casual-data-consumer to get layering right. With the current scheme that is a no-brainer even if there are discrepancies between actual numbering of the floors and what is being used in OSM. Simon PS: addr tags are for postal addresses I don't think using them as a level name/ref makes very much sense outside of that very narrow application. ___ 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] The actual use of the level tag
As tordanik has already pointed out the main issue with the proposals is that there is no inherent ordering that can be deduced from level values on objects if they are not (integer) numbers, so any such scheme requires far more insight, effort and available context from joe-casual-mapper and joe-casual-data-consumer to get layering right. With the current scheme that is a no-brainer even if there are discrepancies between actual numbering of the floors and what is being used in OSM. Simon PS: addr tags are for postal addresses I don't think using them as a level name/ref makes very much sense outside of that very narrow application. signature.asc Description: OpenPGP digital signature ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
