Re: [Tagging] Simplify building:part areas

[Martin Koppenhoefer]

sent from a phone

> On 18. Aug 2017, at 21:06, Javier Sánchez Portero  
> wrote:
> 
> I accept this, although is not clearly expressed in 
> http://wiki.openstreetmap.org/wiki/Key:building:levels
> Does everyone agree that building:levels refers to the maximum number of 
> building levels?


As I have understood established conventions, building:levels are defined in a 
rather complicated and unintuitive way: they are describing all "overground" 
building levels *without the roof levels* and minus the building:min_level. 
They can't deal with split level and don't define when a level is counting as 
"underground" or roof, or in other words how to handle partly underground 
levels. As min levels are linked you will always have to look for min level 
tags if you are interested in building levels. In case of a bridge-like 
building (i.e. levels above a void) you also don't know whose building level 
height / number you have to take for the min level.

To get the number of levels you will have to add building:levels and roof and 
underground levels, and will have to subtract min_levels. As long as it's a 
"simple building", otherwise you will have to invent something better.

Cheers,
Martin 


PS: Yes, it works for the vast majority of actual buildings, only the spatially 
interesting buildings pose problems ;-)


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Simplify building:part areas

[marc marc]

Le 18. 08. 17 à 21:06, Javier Sánchez Portero a écrit :
> http://wiki.openstreetmap.org/wiki/Key:building:levels
> Does everyone agree that building:levels refers to the maximum number of 
> building levels?

This is common sense, irl when you talk about the number of levels of a 
building, it is the maximum number, not an average.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Fire hydrants vs suction_point

[Richard Welty]

On 8/18/17 4:33 PM, Moritz wrote:
>
> Hi Richard
>> in actual real world usage, however, they are called dry hydrants by
>> their
>> users (the fire departments). they are even signed as "dry hydrants" in
>> many
>> cases. there's such a sign not far from me, i can go take a picture of
>> it.
> I think it's a language issue here.
> Here in Germany these dry hydrants are called suction point (actually the 
> German word for it) with proper signs. 
normal practice in these cases is to fall back on british practice.
i have no idea what that might be.

richard

-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Fire hydrants vs suction_point

[Moritz]

Hi Richard
>in actual real world usage, however, they are called dry hydrants by
>their
>users (the fire departments). they are even signed as "dry hydrants" in
>many
>cases. there's such a sign not far from me, i can go take a picture of
>it.

I think it's a language issue here.
Here in Germany these dry hydrants are called suction point (actually the 
German word for it) with proper signs. 

Moritz

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Simplify building:part areas

[Javier Sánchez Portero]

Hello Tobias and Cristian

2017-08-18 17:41 GMT+01:00 Tobias Knerr :

> On 18.08.2017 10:01, Tom Pfeifer wrote:
> > If e.g. the lower floors of the apartment building is wider than the
> > upper floors, you can tag the outline with both, building=apartments and
> > building:part=yes and the appropriate 3D-properties, and the narrower
> > upper floors with building:part=yes and 3D-properties, but without
> > building=*.
>
> It's not a good idea to use building and building:part tags on the same
> way. Doing so typically gives incorrect information to data consumers,
> because the number of levels for the building as a whole is not the same
> as the number of levels for the building part.
>
> In your example, the building part for the lower levels would be tagged:
>
> building:apartments
> + building:part = yes
> + building:levels = 
>

But in the other case, I end up with this:

way1: building = apartments + building:levels = 4
way2: building:part = yes + building:levels = 3
way3: building:part = yes + building:levels = 4
way1 == way2
way3 is inside way1

Josm validation will raises a warning for duplicated ways (way1 and way2).
If I use the open ways + MP relations schema mentioned by Christian, the
situation is almost the same. I will end up with three MP relations instead
of closed ways and Josm validation will raises a warning for relations with
the same members.


> And as you said, one important function of the building outline is
> backwards compatibility for non-3D-applications. Such an application
> will conclude that this building has  levels,
> which is not the case.
>
> Tobias
>

I accept this, although is not clearly expressed in
http://wiki.openstreetmap.org/wiki/Key:building:levels
Does everyone agree that building:levels refers to the maximum number of
building levels?

Javier
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Simplify building:part areas

[Christian Müller]

> Sent: Fri, 18 Aug 2017 09:47:04 +0100
> From: "Javier Sánchez Portero" 
> To: "Tag discussion, strategy and related tools" 
> Subject: Re: [Tagging] Simplify building:part areas
>
> Thank you. This clarifies me a lot because I had not thought to use both 
> building=* and building:part=* in the footprint.


While you can do this, I do not suggest this.  It is prone to the same problems 
we had with closed ways for a long time, which is how to decide which tags 
refer to the outline only and which to the area encased.

OSMs good practices [1] states to create one osm object for each feature in 
reality, so if we describe different parts of one building these are all 
features different from the outline of the building (which may be imagined as a 
rubber band around all of the parts).

Whether you create overlapping ways or multipolygon relations to represent each 
part and the outline, is to some extent up to you.  You will find both methods 
in OSM currently and the community works with and handles both.
Try out kendzi3d plugin if you have not already, to find manifestation of this 
in tools.

However, I personally recommend to stick to a multipolygon approach.  While it 
may not ''seem'' as simple as the closed way approach, it has several 
advantages:

- overlapping ways step back to be used if and only if features truely overlap 
in reality (e.g. a retaining wall below a building wall)
- all ways used in defining multipolygon parts may take tags describing the 
linear feature, which again sticks to the recommendation: "one feature, one 
element"  (e.g. you have a building part with four sides, one made mainly from 
glass, the others with differently coloured plaster, you'd use an mp relation 
to describe the volume as an extruded area, and the individual bounding ways 
will hold wall and material tags)
- neighboring building parts are easily identifiable: the dividing wall (or 
equivalent) will take part in all the relations it divides


Greetings
Christian

[1] 
http://wiki.openstreetmap.org/wiki/Good_practice#One_feature.2C_one_OSM_element

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Simplify building:part areas

[Tobias Knerr]

On 18.08.2017 10:01, Tom Pfeifer wrote:
> If e.g. the lower floors of the apartment building is wider than the
> upper floors, you can tag the outline with both, building=apartments and
> building:part=yes and the appropriate 3D-properties, and the narrower
> upper floors with building:part=yes and 3D-properties, but without
> building=*.

It's not a good idea to use building and building:part tags on the same
way. Doing so typically gives incorrect information to data consumers,
because the number of levels for the building as a whole is not the same
as the number of levels for the building part.

In your example, the building part for the lower levels would be tagged:

building:apartments
+ building:part = yes
+ building:levels = 

And as you said, one important function of the building outline is
backwards compatibility for non-3D-applications. Such an application
will conclude that this building has  levels,
which is not the case.

Tobias

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Fire hydrants vs suction_point

[François Lacombe]

2017-08-18 15:13 GMT+02:00 marc marc :

> another part with
> depreciating fire_hydrant:type=pond <> pressure=0 <> emergency=water_source
>

+1

With 733 664 emergency=fire_hydrant and 4 370 suction_point, this
particular point has chances to make the whole proposal rejected despite
some points have less impact on existing objects.
Eventual move from emergency=fire_hydrant / emergency=suction_point / ...
to emergency=water_supply can be a long term evolution.

Is there anyone from OSMHydrant project in this thread?
As a good render to find hydrants they may have interesting feedbacks
regarding our discussion


All the best
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Fire hydrants vs suction_point

[marc marc]

Le 17. 08. 17 à 16:47, Viking a écrit :
> I'm waiting for other opinions.
colour:bonnet colour:cap colour:reflective seems for me to be in the 
reverse order
the colour of a building is building:colour not colour:building
the same exist with roof:colour light:colour ...

survey:date is the date of a survey (someone was there) not a functional 
check.
it would be better to use check_date (or check:date to keep date suffix)

maybe split the proposal in 2 :

a part with all stuff where it seems to have a consensus
- adding 3 new values for fire_hydrant:type
- adding new keys : wrench class flow_capacity water_source colour 
couplings_type couplings_size wrench
- Migration from fire_hydrant:position=* to location
- Migration from in_service=yes/no to disused:emergency=fire_hydrant

another part with
depreciating fire_hydrant:type=pond <> pressure=0 <> emergency=water_source
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Simplify building:part areas

[marc marc]

First tag the whole building without any "part".
Therefore, building:levels, height refers to the maximum level and 
maximum height of the building, not an average.
If a single closed way is enough to draw a building, you don't need 
multipolygon at this time.
For nearly all applications that don't use "part", only those tag will 
be used.

Then you can add "parts" to better describe the differences in level, 
shape, height, color, type of roof of the different parts of the 
buildings. Those tags will only be used by applications that 
understand/use "parts".
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Simplify building:part areas

[Marco Boeringa]

With building:part you are actually describing 3D volumes. These volumes 
don't necessarily start at ground level, but ideally should not 
intersect in 3D. As you can see in the Simple 3D building specification, 
you can set a "building:min_level" and "min_height" to "raise" a certain 
part from ground level to its appropriate starting height. So in your 
case of a large single story ground level part, and a smaller top 
section, you could set building:min_level and min_height tags on the 
part for the smaller section to raise it above the large section/part, 
which in that case should NOT  be a multipolygon.


Of course, like you suggested, there is the alternative solution of 
creating a multipolygon and setting the higher part to start at ground 
level as well by not specifying building:min_level and min_height, and 
that would be correct too in terms of non-intersecting 3D volumes, but 
the first solution without multipolygon seems more logical in this case 
(unless the higher part was in reality a true separate section starting 
at a ground level, e.g. office, within a larger structure, in which case 
it might make sense to use the MP option if you would like to tag 
function on the building:part as well).


Marco


Op 18-8-2017 om 10:36 schreef Javier Sánchez Portero:
Sorry, I should have taken time to give some examples. Please read 
below (I rev.


2017-08-18 1:30 GMT+01:00 Clifford Snow >:




On Thu, Aug 17, 2017 at 4:12 PM, Javier Sánchez Portero
> wrote:


I am thinking in ways to reduce the complexity that introduces
the mapping of parts of buildings. For example:


I have reversed the order of the points

* In the wiki [1] says that the outline should be tagged with
building:levels and height, but this, if the parts cover the
whole outline, is a duplication since these tags will always
be in some of the parts. Could I delete the part(s) whose
labels match those of the outline?


If you use a multipolygon, then the multipolygon would contain the
levels and height.


I'm refering to 3D modeling of building height and levels, according 
to [1]. For example, this building [2] have two heights and should be 
drawn two parts inside the building footprint, one with 
(building:part=yes, building:levels=1, height=3) [3], and another one 
with (building:part=yes, building:levels=2, height=6). As the building 
footprint [2] could have the levels and height tags I put them in it 
avoiding to draw one part. I meant, the building area is not entirely 
covered by building:part areas. All the building in this village was 
drawn according to this.


I take the rule to put in the building:levels and height tags of the 
full building those of the level wich parts sum a greatest area 
instead of the maximum values. For a example see the adjacent building 
to the left [4]. It have (building:levels=1, height=3) instead of the 
maximum values (building:levels=2, height=6) of the building:part [5]. 
This way I avoid to draw two parts inside the building. I consider 
that the maximum building:levels and height could be calculated by a 
consumer from the building and its parts instead. I'm wrong with it? 
But it's against what says the wiki [6].


* If one part is inscribed within a larger one, can I use
simple ways overlapped and leave to the render decide how to
draw them or should I create a multipolygon for the larger
part with the smaller part with inner role? I'm prone to the
first.


An example would help. If the building has an inner court yard,
then a multipolygon would be appropriate, with the inner court
yard with an inner role.


I'm not referring to buildings with holes but to nested building:part 
areas. Consider this building [7] with a big one-story part and a 
smaller two-story part [8] within it. If I use the full detailled 
schema I will need a multipolygon relation for the one-story part, but 
I avoid this putting the tags in the footprint (violating the rule of 
maximum levels and height in it). I don't have real example at hand, 
but supposes another three-story part inscribed inside the two-story 
part [8]. should I use a multipolygon for the two-story part to fully 
separate it area from the three-story part area? Or could I just draw 
the inner three-story part, overlapping both areas?


[1] https://wiki.openstreetmap.org/wiki/Simple_3D_buildings
[2] http://www.openstreetmap.org/way/459549932
[3] http://www.openstreetmap.org/way/459550128
[4] http://www.openstreetmap.org/way/459549958
[5] http://www.openstreetmap.org/way/459550129
[6] https://wiki.openstreetmap.org/wiki/Key:building:part
[7] http://www.openstreetmap.org/way/215569626
[8] http://www.openstreetmap.org/way/459573978



___
Tagging mailing list

[Tagging] Feature Proposal - RFC - building:architecture:preromanesque

[José G Moya Y .]

I propose this tag to describe middle age buildings created before the
"romanesque revolution" of the 11th century. I guess english people would
like something like "celtic", but I am using "preromanesque" instead of
"celtic" because in Spain there is no "celtic" middle age architecture.

In my country, this tag could be used to describe "mozarabic" buildings
along with "visigothic" buildings. I hope this be useful to other european
countries, too.

Help from art historians would be useful to refine the proposal.

See the link here:

https://wiki.openstreetmap.org/wiki/Proposed_features/building:architecture%
3Dpreromanesque


Yours,

José Moya (Jose M)

El 18/8/2017 10:17, "José G Moya Y."  escribió:

> I am proposed this tag to describe middle age buildings created before the
> "romanesque revolution" of the 11th century. I guess english people would
> like something like "celtic", but I am using "preromanesque" instead of
> "celtic" because in Spain there is no "celtic" middle age architecture.
>
> In my country, this tag could be used to describe "mozarabic" buildings
> along with "visigothic" buildings. I hope this be useful to other european
> countries, too.
>
> Help from art historians would be useful to refine the proposal.
>
> See the link here:
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/
> building:architecture%3Dpreromanesque
>
>
> Yours,
>
> José Moya (Jose M)
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Simplify building:part areas

[Javier Sánchez Portero]

2017-08-18 9:01 GMT+01:00 Tom Pfeifer :

> On 18.08.2017 02:30, Clifford Snow wrote:
>
>> On Thu, Aug 17, 2017 at 4:12 PM, Javier Sánchez Portero <
>> javiers...@gmail.com > wrote:
>> * In the wiki [1] says that the outline should be tagged with
>> building:levels and height, but
>> this, if the parts cover the whole outline, is a duplication since
>> these tags will always be in
>> some of the parts. Could I delete the part(s) whose labels match
>> those of the outline?
>>
>> If you use a multipolygon, then the multipolygon would contain the levels
>> and height.
>>
>
> The building outline represents the "footprint" of the building on the
> ground, and provides all non-3D properties such as building type (e.g.
> building=apartments), address, overall height, etc.
> Thus it provides backward compatibility for a data consumer who does not
> want to evaluate building:part.
>
> If e.g. the lower floors of the apartment building is wider than the upper
> floors, you can tag the outline with both, building=apartments and
> building:part=yes and the appropriate 3D-properties, and the narrower upper
> floors with building:part=yes and 3D-properties, but without building=*.
>
> tom
>


Thank you. This clarifies me a lot because I had not thought to use both
building=* and building:part=* in the footprint.

Javier
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Simplify building:part areas

[Javier Sánchez Portero]

Sorry, I should have taken time to give some examples. Please read below (I
rev.

2017-08-18 1:30 GMT+01:00 Clifford Snow :

>
>
> On Thu, Aug 17, 2017 at 4:12 PM, Javier Sánchez Portero <
> javiers...@gmail.com> wrote:
>
>>
>> I am thinking in ways to reduce the complexity that introduces the
>> mapping of parts of buildings. For example:
>>
>
I have reversed the order of the points

* In the wiki [1] says that the outline should be tagged with
>> building:levels and height, but this, if the parts cover the whole outline,
>> is a duplication since these tags will always be in some of the parts.
>> Could I delete the part(s) whose labels match those of the outline?
>>
>
> If you use a multipolygon, then the multipolygon would contain the levels
> and height.
>

I'm refering to 3D modeling of building height and levels, according to
[1]. For example, this building [2] have two heights and should be drawn
two parts inside the building footprint, one with (building:part=yes,
building:levels=1, height=3) [3], and another one with (building:part=yes,
building:levels=2, height=6). As the building footprint [2] could have the
levels and height tags I put them in it avoiding to draw one part. I meant,
the building area is not entirely covered by building:part areas. All the
building in this village was drawn according to this.

I take the rule to put in the building:levels and height tags of the full
building those of the level wich parts sum a greatest area instead of the
maximum values. For a example see the adjacent building to the left [4]. It
have (building:levels=1, height=3) instead of the maximum values
(building:levels=2, height=6) of the building:part [5]. This way I avoid to
draw two parts inside the building. I consider that the maximum
building:levels and height could be calculated by a consumer from the
building and its parts instead. I'm wrong with it? But it's against what
says the wiki [6].


> * If one part is inscribed within a larger one, can I use simple ways
>> overlapped and leave to the render decide how to draw them or should I
>> create a multipolygon for the larger part with the smaller part with inner
>> role? I'm prone to the first.
>>
>
> An example would help. If the building has an inner court yard, then a
> multipolygon would be appropriate, with the inner court yard with an inner
> role.
>

I'm not referring to buildings with holes but to nested building:part
areas. Consider this building [7] with a big one-story part and a smaller
two-story part [8] within it. If I use the full detailled schema I will
need a multipolygon relation for the one-story part, but I avoid this
putting the tags in the footprint (violating the rule of maximum levels and
height in it). I don't have real example at hand, but supposes another
three-story part inscribed inside the two-story part [8]. should I use a
multipolygon for the two-story part to fully separate it area from the
three-story part area? Or could I just draw the inner three-story part,
overlapping both areas?

[1] https://wiki.openstreetmap.org/wiki/Simple_3D_buildings
[2] http://www.openstreetmap.org/way/459549932
[3] http://www.openstreetmap.org/way/459550128
[4] http://www.openstreetmap.org/way/459549958
[5] http://www.openstreetmap.org/way/459550129
[6] https://wiki.openstreetmap.org/wiki/Key:building:part
[7] http://www.openstreetmap.org/way/215569626
[8] http://www.openstreetmap.org/way/459573978
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Simplify building:part areas

[Tom Pfeifer]

On 18.08.2017 02:30, Clifford Snow wrote:
On Thu, Aug 17, 2017 at 4:12 PM, Javier Sánchez Portero > wrote:

* In the wiki [1] says that the outline should be tagged with 
building:levels and height, but
this, if the parts cover the whole outline, is a duplication since these 
tags will always be in
some of the parts. Could I delete the part(s) whose labels match those of 
the outline?

If you use a multipolygon, then the multipolygon would contain the levels and 
height.


The building outline represents the "footprint" of the building on the ground, and provides all 
non-3D properties such as building type (e.g. building=apartments), address, overall height, etc.

Thus it provides backward compatibility for a data consumer who does not want 
to evaluate building:part.

If e.g. the lower floors of the apartment building is wider than the upper floors, you can tag the 
outline with both, building=apartments and building:part=yes and the appropriate 3D-properties, and 
the narrower upper floors with building:part=yes and 3D-properties, but without building=*.


tom

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging