[Tagging] how to map simple buildings
I have just started mapping according to the simple building scheme and have some questions to the more experienced mappers: A situation I meet very often are buildings consisting in several parts, e.g. often there are higher parts on the (flat) roof that are smaller than the rest. 1. Which representation do you deem preferable: 1.1. map the largest horizontal building extension (e.g. building:levels=5) and add on top a building:part with building:min_level=5, building:levels=1 1.2. map a polygon for only the part that has building:levels=5 leaving out the higher part and add this higher part as building:levels=6 (no min_level here). 1.3. Do you map these as building:part=* and add a third object (in the simplest case) for the building with building=* to combine them? Do you prefer the third object to be a relation or a closed way, and do you add building:level tags as a fallback to it? 2. What is the "roof"? E.g. in the context of flat roofs which are inhabited (apartments, terraces, etc.) 2.1. is this part of the "roof" and the level should not be counted in building:levels (IMHO it is part of the roof): http://www.dach1.at/wp-content/uploads/sl_dach.jpg 2.2 but if 2.1 is part of the "roof", shouldn't this also be 2+1 levels rather than 3? http://media.getrix.it/1/5544/2488638989.jpg 2.3 similarly, is this 5+1 or 6 levels? https://imganuncios.mitula.net/casa_di_200_mq_a_collina_fleming_vigna_clara_roma_4010133485552255323.jpg 2.4 there are also cases where inclined tiles have been applicated later to prefabricated houses with flat roofs to make them look more similar to traditional houses. Inside the house has remained the same, but from the street it now looks as if there was kind of inclined roof. 3. Am I right that this is not representable with the simple building model? (It's a rotated roof, not parallel with the building sides) http://www.cityastronomy.com/exterior-open.jpg Thank you, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] how to map simple buildings
I usually go for a mixture of 1.1. and 1.3., i.e. - use building:part for the architectural blocks the building is made of, with building:min_height / building:min_level where appropiate - use type=multipolygon building=*, stuff the usual building tags into that, this will be rendered by non-aware 3d renderers, i.e. serves backward compat and will be added in role outline to the following - use type=building relation to group together outline and parts, see http://wiki.openstreetmap.org/wiki/Relation:building (though I've never used ridge or edge roles) See http://www.openstreetmap.org/relation/2436669 for an example that deals with the exact same problem you describe (level 2 having larger extents than ground level). As for your point 2. - afair simple buildings allows to define roofs only along with building:part, so there is no extra mechanism to define roof elements separated from those. If you have a roof that deviates a lot from the building parts it covers (or you want to define the roof as a single object covering a lot of building parts), you can "hack" around the proposal's limitation by using extra building parts for the roof elements in question (or single roof) that lack a building level and only account for the resp. roof levels. In part this method can be challenged by "we do not tag for renderers" principle, but there is no other alternative for in-db 3d building mapping that I know of (and that is as widely used as the simple building proposal). Most frequent you will be tempted to use this "hack" for full building connectors (not skyways that are limited to a subset of stories/levels): If you have a hipped roof on the main building parts and a gabled one covering the connector part and their roofs are at same height, the roof outline of the connector will overlap that of the levels below. There are two solutions to this: - model connector's roof separately (i.e. using two building:part relations - extend the outline of the connector as a whole into the main building parts it connects For the first solution you could argue: "but it's only one building part not two, and if the levels below are mapped separately a flat roof will be silently assumed, where a gabled one is attached, but modeled separately" For the second solution you might get problems with indoor mappers in time. Both are to some degree "quick and dirty", but then that may be true for the whole simple building proposal. It's acclaimed to be 'simple' for a reason and does not account for some of the specialities in architecture you'll find out there. IMO this is a good thing, because this also limits data size (it naturally deflates real data, because mappers go for the most dominant parts of a building and do not loose themselves in details). For feature-rich buildings with lot of small detail that is hard to capture with the simple buildings proposal, you could still go for an external model, store the data elsewhere and mash it, like f4-map does. Greetings Gesendet: Donnerstag, 02. März 2017 um 14:09 Uhr Von: "Martin Koppenhoefer" An: "Tag discussion, strategy and related tools" Betreff: [Tagging] how to map simple buildings I have just started mapping according to the simple building scheme and have some questions to the more experienced mappers: A situation I meet very often are buildings consisting in several parts, e.g. often there are higher parts on the (flat) roof that are smaller than the rest. 1. Which representation do you deem preferable: 1.1. map the largest horizontal building extension (e.g. building:levels=5) and add on top a building:part with building:min_level=5, building:levels=1 1.2. map a polygon for only the part that has building:levels=5 leaving out the higher part and add this higher part as building:levels=6 (no min_level here). 1.3. Do you map these as building:part=* and add a third object (in the simplest case) for the building with building=* to combine them? Do you prefer the third object to be a relation or a closed way, and do you add building:level tags as a fallback to it? 2. What is the "roof"? E.g. in the context of flat roofs which are inhabited (apartments, terraces, etc.) 2.1. is this part of the "roof" and the level should not be counted in building:levels (IMHO it is part of the roof): http://www.dach1.at/wp-content/uploads/sl_dach.jpg 2.2 but if 2.1 is part of the "roof", shouldn't this also be 2+1 levels rather than 3? http://media.getrix.it/1/5544/2488638989.jpg 2.3 similarly, is this 5+1 or 6 levels? https://imganuncios.mitula.net/casa_di_200_mq_a_collina_fleming_vigna_clara_roma_4010133485552255323.jpg 2.4 there are also cases where inclined tiles have been applicated later to prefabricated houses with flat roofs to make them look more similar to traditional houses. Inside the house has remained the same, but from the street it n
Re: [Tagging] how to map simple buildings
Also note that there are some implications in 2d mapnik rendering. With the building outline we define and the mapnik rules that were set upto render everything highway=* _above_ anything else, the renderer _will_ overlap a building outline with a pedestrian area. Esp. when (highway=pedestrian area=yes) connects seamless to the ground level building part: __ building outline extents up to here / | v ._flat_roof_ | level 3 |___ | level 2 |___ | ground level pedestrian | area outside |__ ^~ pedestrian area extents up to here Greetings ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] how to map simple buildings
> Gesendet: Donnerstag, 02. März 2017 um 14:09 Uhr > Von: "Martin Koppenhoefer" > An: "Tag discussion, strategy and related tools" > Betreff: [Tagging] how to map simple buildings > > I have just started mapping according to the simple building scheme > and have some questions to the more experienced mappers: > > A situation I meet very often are buildings consisting in several parts, > e.g. often there are higher parts on the (flat) roof that are smaller > than the rest. Sorry for having sent a reply as HTML the first time, here is a plain text copy of that answer: I usually go for a mixture of 1.1. and 1.3., i.e. - use building:part for the architectural blocks the building is made of, with building:min_height / building:min_level where appropiate - use type=multipolygon building=*, stuff the usual building tags into that, this will be rendered by non-aware 3d renderers, i.e. serves backward compat and will be added in role outline to the following - use type=building relation to group together outline and parts, see http://wiki.openstreetmap.org/wiki/Relation:building (though I've never used ridge or edge roles) See http://www.openstreetmap.org/relation/2436669 for an example that deals with the exact same problem you describe (level 2 having larger extents than ground level). As for your point 2. - afair simple buildings allows to define roofs only along with building:part, so there is no extra mechanism to define roof elements separated from those. If you have a roof that deviates a lot from the building parts it covers (or you want to define the roof as a single object covering a lot of building parts), you can "hack" around the proposal's limitation by using extra building parts for the roof elements in question (or single roof) that lack a building level and only account for the resp. roof levels. In part this method can be challenged by "we do not tag for renderers" principle, but there is no other alternative for in-db 3d building mapping that I know of (and that is as widely used as the simple building proposal). Most frequent you will be tempted to use this "hack" for full building connectors (not skyways that are limited to a subset of stories/levels): If you have a hipped roof on the main building parts and a gabled one covering the connector part and their roofs are at same height, the roof outline of the connector will overlap that of the levels below. There are two solutions to this: - model connector's roof separately (i.e. using two building:part relations - extend the outline of the connector as a whole into the main building parts it connects For the first solution you could argue: "but it's only one building part not two, and if the levels below are mapped separately a flat roof will be silently assumed, where a gabled one is attached, but modeled separately" For the second solution you might get problems with indoor mappers in time. Both are to some degree "quick and dirty", but then that may be true for the whole simple building proposal. It's acclaimed to be 'simple' for a reason and does not account for some of the specialities in architecture you'll find out there. IMO this is a good thing, because this also limits data size (it naturally deflates real data, because mappers go for the most dominant parts of a building and do not loose themselves in details). For feature-rich buildings with lot of small detail that is hard to capture with the simple buildings proposal, you could still go for an external model, store the data elsewhere and mash it, like f4-map does. Greetings ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] how to map simple buildings
Thank you for the extensive answer. Here are some comments: 2017-03-02 15:24 GMT+01:00 "Christian Müller" : > I usually go for a mixture of 1.1. and 1.3., i.e. > > - use building:part for the architectural blocks the building is made of, > with building:min_height / building:min_level where appropiate > > - use type=multipolygon building=*, stuff the usual building tags into > that, > this will be rendered by non-aware 3d renderers, i.e. serves backward > compat > and will be added in role outline to the following > > - use type=building relation to group together outline and parts, > see http://wiki.openstreetmap.org/wiki/Relation:building > (though I've never used ridge or edge roles) > do I understand you correctly, we use 1 way (or multipolygon) for every building:part plus 1 multipolygon relation with building=* as a fallback plus 1 type=building relation for every single building? That's a lot of stuff, but it sounds reasonable in order to map everything in an unambiguous way. > > As for your point 2. - afair simple buildings allows to define > roofs only along with building:part, so there is no extra > mechanism to define roof elements separated from those. > yes, my question was refering to the building:levels tag: where to count the levels, as part of the roof or of the "main part" of the building > > If you have a roof that deviates a lot from the building > parts it covers (or you want to define the roof as a single > object covering a lot of building parts), you can "hack" > around the proposal's limitation by using extra building > parts for the roof elements in question (or single roof) > that lack a building level and only account for the resp. > roof levels. > good point Cheers, Martin btw.: there's only one aspect of the simple building model which I really detest: the way building:levels in defined for buildings that have "missing" levels. IMHO it should express the number of building levels (like it says), not be a partial information where you have to subtract building:min_level to get the actual building levels number. ...and in case there's a "bridge building" like in the example: https://wiki.openstreetmap.org/wiki/File:Minlevel.svg the suggestion should really be to use "min_height", as it will often not be clear to which building or floor_height building:min_level refers to (the (existing) levels of the object that has this tag, the left or the right building, or a "standard height"?) ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Invalid voting of proposed feature motorcycle_friendly=*
Hi, I have been informed by another mapper who uses XING (the German LikedIn) that there is a new tag motorcycle_friendly=yes. [1] Its wiki page says that the key has been proposed and accepted. https://wiki.openstreetmap.org/wiki/Key:motorcycle_friendly The proposal page can be found here: https://wiki.openstreetmap.org/wiki/Proposed_features/motorcycle_friendly The RFC was announced on this mailing list on January 10, 2017. https://lists.openstreetmap.org/pipermail/tagging/2017-January/030844.html If you have a slight look at the proposal box at the top of the proposal page on the wiki, you will discover that the RFC phase was only one week although the proposal "guideline" says [2]: > At least two weeks after the RFC, and once problems brought up in > discussion have been resolved by modifying the proposal, send out a > Request for Voting to the tagging mailing list In addition only the RFC was announced at this mailing list but the voting has not been announced. Therefore it is no surprise that the proposal was "accepted" by 13 users and only 3 users opposed. I think that most of these users are friends of the user who proposes the tag because they only have one edit at the wiki – their voting for this proposal. Because the proposal violated the guideline, I would like to - remove the status "proposed" from its feature documentation page - reset the status of the proposal to "RFC" - to declare the voting as invalid by adding a note at the top of the voting section - add a note to the feature documentation page linking to this email and explaining that the voting was invalid. What is your opinion? Best regards Michael [1] XING users can open the link: https://www.xing.com/communities/posts/fuer-die-motorradfahrer-unter-den-mappern-pois-1012765773 [2] https://wiki.openstreetmap.org/wiki/Proposal_process#Voting -- Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten ausgenommen) I prefer GPG encryption of emails. (does not apply on mailing lists) signature.asc Description: OpenPGP digital signature ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Invalid voting of proposed feature motorcycle_friendly=*
Hi Michael, On 02.03.2017 20:21, Michael Reichert wrote: Because the proposal violated the guideline, I would like to - remove the status "proposed" from its feature documentation page - reset the status of the proposal to "RFC" - to declare the voting as invalid by adding a note at the top of the voting section - add a note to the feature documentation page linking to this email and explaining that the voting was invalid. I agree with your observations and your proposed actions. While it's ok to overlook minor "rule violations" sometimes, things like not announcing the vote do clearly have a big impact on the outcome. It's obvious to me that the vote is invalid and needs to be repeated. Thanks a lot for your vigilance! Tobias ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Mapping freeway stub ends?
+1 on highway=construction + construction=* + access is no if non-accessible If accessible (such as https://www.openstreetmap.org/search?query=delta%2C%20be#map=18/50.81538/4.40527&layers=N / https://www.google.nl/maps/place/P%2BR+Delta/@50.8154748,4.4032357,261m/data=!3m1!1e3!4m5!3m4!1s0x47c3db326031c4e3:0x35e99857d1a0!8m2!3d50.8161931!4d4.4060433 where a stub highway is used as a de-facto parking site and access to a work site, I'd use highway=service. A nearby highway was torn down (in favor of a new highway), yet pieces of the old highway are still present (as a demolition traffic road). Since the old road has no classification as highway anymore, I tagged it as highway=road (+access=none), which could also apply to such cases Tijmen / IIVQ ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Invalid voting of proposed feature motorcycle_friendly=*
On 03-Mar-17 06:55 AM, Tobias Knerr wrote: Hi Michael, On 02.03.2017 20:21, Michael Reichert wrote: Because the proposal violated the guideline, I would like to - remove the status "proposed" from its feature documentation page - reset the status of the proposal to "RFC" - to declare the voting as invalid by adding a note at the top of the voting section - add a note to the feature documentation page linking to this email and explaining that the voting was invalid. I agree with your observations and your proposed actions. While it's ok to overlook minor "rule violations" sometimes, things like not announcing the vote do clearly have a big impact on the outcome. It's obvious to me that the vote is invalid and needs to be repeated. In addition I would remove the status=approved from the https://wiki.openstreetmap.org/wiki/Key:motorcycle_friendly page. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Invalid voting of proposed feature motorcycle_friendly=*
sent from a phone > On 2 Mar 2017, at 20:55, Tobias Knerr wrote: > > While it's ok to overlook minor "rule violations" sometimes, things like not > announcing the vote do clearly have a big impact on the outcome. It's obvious > to me that the vote is invalid and needs to be repeated. +1 cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] how to map simple buildings
> Gesendet: Donnerstag, 02. März 2017 um 17:19 Uhr > Von: "Martin Koppenhoefer" > An: "Christian Müller" > Cc: "Tag discussion, strategy and related tools" > Betreff: Re: [Tagging] how to map simple buildings > > do I understand you correctly, we use 1 way (or multipolygon) for every > building:part plus 1 multipolygon relation with building=* as a [legacy] > plus 1 type=building relation for every single building? That's a lot of > stuff, but it sounds reasonable in order to map everything in an > unambiguous way. Yes, but you only need to do it for buildings with more than one part. For non-complex buildings 1 MP relation holding all tags may suffice. (or even a single closed way, if none of its segments ought to take part in definition of adjacent areas) There are a lot of aspects of the simple building model with room for improvement. Among them the most important: documentation in the wiki. It looks unfinished and could benefit a lot from additional examples. Cheers ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Mapping freeway stub ends?
> On Mar 2, 2017, at 12:40 PM, Tijmen Stam wrote: > > +1 on highway=construction + construction=* + access is no if non-accessible > If accessible (such as > https://www.openstreetmap.org/search?query=delta%2C%20be#map=18/50.81538/4.40527&layers=N > / > https://www.google.nl/maps/place/P%2BR+Delta/@50.8154748,4.4032357,261m/data=!3m1!1e3!4m5!3m4!1s0x47c3db326031c4e3:0x35e99857d1a0!8m2!3d50.8161931!4d4.4060433 > where a stub highway is used as a de-facto parking site and access to a work > site, I'd use highway=service. > > A nearby highway was torn down (in favor of a new highway), yet pieces of the > old highway are still present (as a demolition traffic road). > Since the old road has no classification as highway anymore, I tagged it as > highway=road (+access=none), which could also apply to such cases > I was under the impression that highway=road was only for situations where the details about the road were unknown and a field survey was required to determine the correct classification. I think I’d use highway=unclassified in the case you describe. Unless, of course, the way is being used for something else (I’ve seen a number of places where an old main highway was turned over to the adjacent property owners and is now used as a private service road). ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] how to map simple buildings
I'm hijacking the thread a bit here, but the discussion of "bridge buildings" in Martin's message made me think of this: On the campus of GE Research in Niskayuna, New York, there's a fairly substantial building that is on a bridge across a ravine. >From the way it renders, I think that I've probably mistagged it. Also, JOSM warned me of a suspicious bridge=yes, but I figured that's just because buildings usually aren't on bridges. But it surely looks weird in the rendering. Is there something I should have done differently here? ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Invalid voting of proposed feature motorcycle_friendly=*
On 03-Mar-17 09:51 AM, Martin Koppenhoefer wrote: sent from a phone On 2 Mar 2017, at 20:55, Tobias Knerr wrote: While it's ok to overlook minor "rule violations" sometimes, things like not announcing the vote do clearly have a big impact on the outcome. It's obvious to me that the vote is invalid and needs to be repeated. +1 From reading the few comments on the wiki discussion page ... It looks like this should be a property tag of "friendly:*=yes/no" Where * could be motorcycle, hiking, bicycle etc. Should I start a proposal along these lines? There are presently <100 motorcycle_friendly occurrences in the data base so replacing them would not be too much work. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
