Re: Tagging Digest, Vol 113, Issue 73

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Tagging Digest, Vol 113, Issue 73

St Niklaas
Hi Stephan & all,

I realised this see the lines below,

Sergio Manzi <[hidden email]>
Za 16-2-2019 16:06

Hello!


Actually the analysis was not mine, but just the result of a query in taginfo (https://taginfo.openstreetmap.org/keys/?key=building%3Astart_date), but I guess I understand what's going on here:


all of the objects you're referring are tagged with a start_date=* key, while the tag I was referring to (and was discussed in the mailing list) is building:start_date=* (note the presence of the "building:" namespace prefix...).


A query for "your" key (https://taginfo.openstreetmap.org/keys/?key=start_date) returns 14246906 objects!!


I don't know how many of those more than 14 millions objects are buildings, but I suspect quite a good number (an appropriate query in overpass turbo can clarify that, I guess).


Normally I'm all in for supporting namespaces, but I understand that we have a problem here and it would be just silly to throw away such a bunch of good information.


I suggest you to answer to the mailing list too and underline this situation. You can quote my answer in full or in part, if you wish.


Regards and my compliments for your outstanding contribution,


Sergio




On 2019-02-16 15:42, St Niklaas wrote:

Hi Sergio,


I doubt your analyses, since almost all buildings (5 million) in the Netherlands that have been imported since 2014, carry  "start_date = 2022" or alike. Have a look here https://www.openstreetmap.org/#map=19/52.53890/4.83687

The import comes straight out of the Dutch Cadastre after a lot of hard work getting the go ahead from the government. But my contributions are not among them, the BAG (Basis Addresses and Buildings) don’t measure covered buildings even if they are historic monuments, so that’s my speciality and they import my OSM work into the BAG 🙂


Greetz



OpenStreetMap is the free wiki world map. OpenStreetMap is a map of the world, created by people like you and free to use under an open license.





_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: start_date variants

Stephan Bösch-Plepelits-2
I'm a bit confused by this thread, somehow I have the impression I missed
something (that's why I left TOFU in this mail).

Anyway, I'd like to summarize:

There are many-many objects (most of them buildings - 96%) tagged with
start_date=* - I think, that's great. start_date is quite well documented
and very flexible concerning ranges and approximations.

My suggestion was to use a prefix "building:" if the start_date of the
building differs from the start_date of the amenity. It is not very common
though right now, with only 163 uses. Only 9 have both start_date and
building:start_date.

When investigating this issue - triggered by this thread, I/we discovered
that there are alternative building age tagging schemes.

I made a search through taginfo and found some more tags:

* "building:age" - very popular (132071), but rather useless. 41% have the
  value "post_2000", 19% "pre_2000". 12.9% "10_to_30" (should this mean "
  10 to 30 years? - this is wrong on so many levels, I don't even know where to
  start).
  It's documented on the start_date page as possible tagging mistake.
  https://taginfo.openstreetmap.org/keys/building%3Aage#values
* "building:year_built" - some (3005). Mostly start year or in some cases
  approximations (but different syntax from start_date).
  I found no documentation at all.
  https://taginfo.openstreetmap.org/keys/building%3Ayear_built#values
* "building:buildyear" - some (2051). Only very few objects use
  approxiations.
  As mentioned by Sergio, it was introduced in the IndoorOSM proposal.
  https://taginfo.openstreetmap.org/keys/building%3Abuildyear#values
* "year_built" - some (2417, whereas many might not be buildings).
  No documentation.
  https://taginfo.openstreetmap.org/keys/year_built#values
* "building:year" - few (102).
  It's documented on the start_date page as possible tagging mistake.
  https://taginfo.openstreetmap.org/keys/building:year#values

It seems, that 'start_date' is be the preferred way to tag the age of a
building. Tag is popular and well documented.
I took the liberty of adding it to the additional attribute section on
https://wiki.openstreetmap.org/wiki/Key:building

What I wanted, was to introduce a way to highlight different start_dates
for the same object (e.g. old building, new use). I personally
would prefer 'building:start_date' as fallback, as it uses the same syntax
as start_date. And it could be applied to other keys as well (and this is
being used).

Do you think, that any of the other tags should be supported as well?
 
Anyway, I will modify the OpenStreetBrowser category to also supprt
"building:year_built", "building:buildyear", "yearbuilt" and
"building:year" (but with the syntax of the start_date tag). "building:age"
will be shown red (date format not supported).

I'm planning to introduce some quality assurance tools in OpenStreetBrowser
in the near future. I would show these alternative tagging schemes as
warnings.

greetings,
        Stephan

On Sat, Feb 16, 2019 at 04:08:03PM +0000, St Niklaas wrote:

> Hi Stephan & all,
>
> I realised this see the lines below,
>
> Sergio Manzi <[hidden email]>
> Za 16-2-2019 16:06
>
> Hello!
>
>
> Actually the analysis was not mine, but just the result of a query in taginfo (https://taginfo.openstreetmap.org/keys/?key=building%3Astart_date), but I guess I understand what's going on here:
>
>
> all of the objects you're referring are tagged with a start_date=* key, while the tag I was referring to (and was discussed in the mailing list) is building:start_date=* (note the presence of the "building:" namespace prefix...).
>
>
> A query for "your" key (https://taginfo.openstreetmap.org/keys/?key=start_date) returns 14246906 objects!!
>
>
> I don't know how many of those more than 14 millions objects are buildings, but I suspect quite a good number (an appropriate query in overpass turbo can clarify that, I guess).
>
>
> Normally I'm all in for supporting namespaces, but I understand that we have a problem here and it would be just silly to throw away such a bunch of good information.
>
>
> I suggest you to answer to the mailing list too and underline this situation. You can quote my answer in full or in part, if you wish.
>
>
> Regards and my compliments for your outstanding contribution,
>
>
> Sergio
>
>
>
>
> On 2019-02-16 15:42, St Niklaas wrote:
>
> Hi Sergio,
>
>
> I doubt your analyses, since almost all buildings (5 million) in the Netherlands that have been imported since 2014, carry  "start_date = 2022" or alike. Have a look here https://www.openstreetmap.org/#map=19/52.53890/4.83687
>
> The import comes straight out of the Dutch Cadastre after a lot of hard work getting the go ahead from the government. But my contributions are not among them, the BAG (Basis Addresses and Buildings) don’t measure covered buildings even if they are historic monuments, so that’s my speciality and they import my OSM work into the BAG 🙂
>
>
> Greetz
>
>
> [https://www.openstreetmap.org/assets/osm_logo_256-cde84d7490f0863c7a0b0d0a420834ebd467c1214318167d0f9a39f25a44d6bd.png]<https://www.openstreetmap.org/#map=19/52.53890/4.83687>
>
> OpenStreetMap<https://www.openstreetmap.org/#map=19/52.53890/4.83687>
> OpenStreetMap is the free wiki world map. OpenStreetMap is a map of the world, created by people like you and free to use under an open license.
> www.openstreetmap.org<http://www.openstreetmap.org>
>
>
>
> ________________________________
>
--
Seid unbequem, seid Sand, nicht Öl im Getriebe der Welt! - Günther Eich
,----------------------------------------------------------------------.
| Stephan Bösch-Plepelits  ❤ code ❤ urbanism ❤ free software ❤ cycling |
| Projects:                                                            |
| > OpenStreetMap: openstreetbrowser.org > openstreetmap.at            |
| > Urbanism: Radlobby Wien                                            |
| Contact:                                                             |
| > Mail: [hidden email] > Blog: plepe.at > Code: github.com/plepe |
| > Twitter: twitter.com/plepe > Jabber: [hidden email]               |
| > Mastodon: @[hidden email]                                       |
`----------------------------------------------------------------------'

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

signature.asc (828 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: start_date variants

Sergio Manzi
Stephan, can you point to any such object in OSM where you find that ambiguity?

I have the feeling that we could possibly discover a violation of the "One feature, one OSM element" principle [1] in there...

Sergio

[1] https://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element


On 2019-02-16 22:01, Stephan Bösch-Plepelits wrote:
> My suggestion was to use a prefix "building:" if the start_date of the
> building differs from the start_date of the amenity. It is not very common
> though right now, with only 163 uses. Only 9 have both start_date and
> building:start_date.


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: start_date variants

Anton Klim
Like in the thread opening email, where there is an amenity that occupies the whole building, we put amenity tags on the outline.
I generally support adding more granularity to start_date, but feel like start_date:* might fit better than *:start_date.

Anton Klim

> 16 февр. 2019 г., в 21:40, Sergio Manzi <[hidden email]> написал(а):
>
> Stephan, can you point to any such object in OSM where you find that ambiguity?
>
> I have the feeling that we could possibly discover a violation of the "One feature, one OSM element" principle [1] in there...
>
> Sergio
>
> [1] https://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element
>
>
>> On 2019-02-16 22:01, Stephan Bösch-Plepelits wrote:
>> My suggestion was to use a prefix "building:" if the start_date of the
>> building differs from the start_date of the amenity. It is not very common
>> though right now, with only 163 uses. Only 9 have both start_date and
>> building:start_date.
>
> _______________________________________________
> Tagging mailing list
> [hidden email]
> https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: start_date variants

Sergio Manzi
Then I guess the correct solution would be to not "stick" the amenity to the building but to a new relation whose only member will be the building itself.

One further benefit is that if the amenity goes you can delete the relation without disturbing the building...

Sergio


On 2019-02-16 23:49, Anton Klim wrote:

> Like in the thread opening email, where there is an amenity that occupies the whole building, we put amenity tags on the outline.
> I generally support adding more granularity to start_date, but feel like start_date:* might fit better than *:start_date.
>
> Anton Klim
>
>> 16 февр. 2019 г., в 21:40, Sergio Manzi <[hidden email]> написал(а):
>>
>> Stephan, can you point to any such object in OSM where you find that ambiguity?
>>
>> I have the feeling that we could possibly discover a violation of the "One feature, one OSM element" principle [1] in there...
>>
>> Sergio
>>
>> [1] https://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element
>>
>>
>>> On 2019-02-16 22:01, Stephan Bösch-Plepelits wrote:
>>> My suggestion was to use a prefix "building:" if the start_date of the
>>> building differs from the start_date of the amenity. It is not very common
>>> though right now, with only 163 uses. Only 9 have both start_date and
>>> building:start_date.
>> _______________________________________________
>> Tagging mailing list
>> [hidden email]
>> https://lists.openstreetmap.org/listinfo/tagging
> _______________________________________________
> Tagging mailing list
> [hidden email]
> https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: start_date variants

dieterdreist
In reply to this post by Anton Klim


sent from a phone

> On 16. Feb 2019, at 23:49, Anton Klim <[hidden email]> wrote:
>
> Like in the thread opening email, where there is an amenity that occupies the whole building, we put amenity tags on the outline.


I agree with Serge here, when there is a problem where it is not clear to what the tags refer, it is usually a modeling problem of mixing different things up in one object, and a better solution than creating more specific tags by prefixing them, would be to fix the model. It will not end at start_date ;-)

Cheers, Martin



_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: start_date variants

Sergio Manzi

Yeah. The "other" solution could be to "namespace everything", so you could tag building:whatever_property_key_you_want and amenity:whatever_property_key_you_want, applied to the very same object. But we're probably too late for that and apparently many seems to hate this latter solution.

On 2019-02-16 23:59, Martin Koppenhoefer wrote:

sent from a phone

On 16. Feb 2019, at 23:49, Anton Klim [hidden email] wrote:

Like in the thread opening email, where there is an amenity that occupies the whole building, we put amenity tags on the outline. 

I agree with Serge here, when there is a problem where it is not clear to what the tags refer, it is usually a modeling problem of mixing different things up in one object, and a better solution than creating more specific tags by prefixing them, would be to fix the model. It will not end at start_date ;-)

Cheers, Martin 



_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: start_date variants

Anton Klim
There've been quite a lot of discussions lately about namespaces and indeed current osm tagging is clunky in that regard.
not sure if relations are a good fix though

сб, 16 февр. 2019 г. в 23:07, Sergio Manzi <[hidden email]>:

Yeah. The "other" solution could be to "namespace everything", so you could tag building:whatever_property_key_you_want and amenity:whatever_property_key_you_want, applied to the very same object. But we're probably too late for that and apparently many seems to hate this latter solution.

On 2019-02-16 23:59, Martin Koppenhoefer wrote:
sent from a phone

On 16. Feb 2019, at 23:49, Anton Klim [hidden email] wrote:

Like in the thread opening email, where there is an amenity that occupies the whole building, we put amenity tags on the outline. 
I agree with Serge here, when there is a problem where it is not clear to what the tags refer, it is usually a modeling problem of mixing different things up in one object, and a better solution than creating more specific tags by prefixing them, would be to fix the model. It will not end at start_date ;-)

Cheers, Martin 



_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: start_date variants

Sergio Manzi

Currently, and AFAIK, relations are the only solution for modeling situations like the one you described...

On 2019-02-17 00:40, Anton Klim wrote:
not sure if relations are a good fix though

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: start_date variants

Stephan Bösch-Plepelits-2
In reply to this post by Sergio Manzi
On Sat, Feb 16, 2019 at 11:53:52PM +0100, Sergio Manzi wrote:
> Then I guess the correct solution would be to not "stick" the amenity to the building but to a new relation whose only member will be the building itself.
>
Yeah, that was the other solution I thought of.

In the particular case which I was describing in the opening mail
https://www.openstreetmap.org/relation/1937535
the building is already a multipolygon relation.

Do you think a relation with a multipolygon relation as member would work?
Or would it be better to duplicate the multipolygon relation?

Logically I would prefer the first solution, but I have doubts on the
technical support.

greetings,
        Stephan
--
Seid unbequem, seid Sand, nicht Öl im Getriebe der Welt! - Günther Eich
,----------------------------------------------------------------------.
| Stephan Bösch-Plepelits  ❤ code ❤ urbanism ❤ free software ❤ cycling |
| Projects:                                                            |
| > OpenStreetMap: openstreetbrowser.org > openstreetmap.at            |
| > Urbanism: Radlobby Wien                                            |
| Contact:                                                             |
| > Mail: [hidden email] > Blog: plepe.at > Code: github.com/plepe |
| > Twitter: twitter.com/plepe > Jabber: [hidden email]               |
| > Mastodon: @[hidden email]                                       |
`----------------------------------------------------------------------'

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: start_date variants

Sergio Manzi

Hi Stephan!

Yes, a relation can be made up of a relation: no problem with that, AFAIK.

In your particular case, anyway, I'm afraid there is something wrong:

https://www.openstreetmap.org/relation/1937535 (name=MuseumsQuartier) is tagged as "building=yes" and also with "building:architecture=baroque", but in reality MusemQuartier is not "a" building, but an area, a cultural district (on https://www.mqw.at/en/ I read "MuseumsQuartier Wien is one of the largest districts for contemporary art and culture in the world"), made up of several different buildings ranging from the baroque to the contemporary era.

MuseumsQuartier (the district) is already mapped with https://www.openstreetmap.org/way/335982323 as both a tourism=attraction and landuse=commercial (yeah... I know... it seems we miss a specific tag for cultural districts and I think that's something we should address...), and several of the tags applied to relation 1937535 (e.g. wikidata=*, wikipedia=*) are already there. Anything globally related to the MuseumsQuartier cultural district should be tagged on that way.

If relation 1937535 is meant to map one of the several buildings which are part of the MuseumQuartier district, then anything related to the district should be deleted from it and probably the name should also be changed: a building is not a quartier and I suppose the correct name for that particular building (the baroque building encompassing the district) to be Hofstallungen.

The "building:start_date=1725" tag should be modified into just a "start_date=1725" tag, and the "start_date=2001-06..2001-09" tag should be instead applied to the quartier (the way...) if it is a property of the district, or, if it is meant to indicate the date of the Hofstallungen renewal, it should probably go into a note of the 1937535 relation or we could use and document a "renewal_date=*" key (there is already 1 usage for that, here: https://www.openstreetmap.org/relation/7255270).

Cheers!

Sergio


On 2019-02-17 08:07, Stephan Bösch-Plepelits wrote:
In the particular case which I was describing in the opening mail
https://www.openstreetmap.org/relation/1937535
the building is already a multipolygon relation.

Do you think a relation with a multipolygon relation as member would work?
Or would it be better to duplicate the multipolygon relation?

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: start_date variants

Markus-5
In reply to this post by Sergio Manzi

On Sat, 16 Feb 2019, 23:55 Sergio Manzi <[hidden email] wrote:
Then I guess the correct solution would be to not "stick" the amenity to the building but to a new relation whose only member will be the building itself.

+ 1

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: start_date variants

Markus-5
In reply to this post by Stephan Bösch-Plepelits-2
On Sun, 17 Feb 2019, 08:09 Stephan Bösch-Plepelits <[hidden email] wrote:
Do you think a relation with a multipolygon relation as member would work?
Or would it be better to duplicate the multipolygon relation?

A multipolygon can only consist of ways (with the roles outer and inner), so you need to duplicate the relation.

For objects inside smaller buildings i think a node would be enough.

Regards

Markus

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging