[Imports] Import plan: Japan Plateau building dataset
Satoshi IIDA
nyampire at gmail.com
Fri Aug 12 06:18:32 UTC 2022
Hello Marc,
Thank you for the feedback!
> https://wiki.openstreetmap.org/wiki/MLIT_PLATEAU/imports_outline
> Schedule section, questionnaire Result: here" have a missing link
Ouch, I missed it!
> Tagging Plans : comment contain a lot of non-english stuff,
> I'm unable to understand those comments
Also, I've added the translation lines. Could you check those?
https://wiki.openstreetmap.org/wiki/MLIT_PLATEAU/imports_outline#Data_Preparation
> "by providing a ref tag for the objects, it simplifies the update
> process on the OSM side for future updates" : it's a dogma, a myth:
> don't add it if it's information for a script
OK, I see. I'll remove it. (and also remove the "for future updates" line)
> addr:full : I don't know about the address system in your country
> but isn't it possible to split addr:full into the more precise tags
> that exist? I think addr:full exists for cases where an addr doesn't
> fit in the general case (or as a temporary tag)
> another solution is to separate the import of buildings <> import of addr
We have 2 issues regarding this task.
1. Very few objects have this value in raw data.
2. We have no parser for this separation.
Japanese community had a long, long discussion about updating addr:*
structure.
And it is almost solved recently. So we have no parsers yet.
I'm going to ask the team if we can have a separate plan as you suggest.
> Tag merge : I don't like the idea of automatically overwriting the values
in osm with the values from the import.
Yes, this is also mentioned in the local discussion. I agree with you, but
I think this has fewer impacts.
1. This is "semi-"automatically. It needs checks by an importer during the
workflow.
2. 99.9% of Plateau objects do not have the specific building:* value...
Actually, I had very excited when I saw the specification of the Plateau
dataset. And the Plateau project says "39 of 56 datasets have the value!".
But I've disappointed as I checked the raw data. A very few objects have
this value, and even the value is not used in some of the datasets.
So the conflict would be quite rare, and we can find it in the import
workflow process.
> Changeset Tags : add a good changeset description, for ex :importing
building outline/height/levels/ele/start_date/addr
Thank you!
But each municipality/dataset covers different tags. (most of the datasets
have simply outline/ele/height, another has addr/start_date... and so on.
Detail available on
https://gic-plateau.s3.ap-northeast-1.amazonaws.com/2020/attributedata.xlsx)
And even each changeset has different target tags. This approach might be
slightly complex for importer and checker both.
So how about making a wiki page for listing "target tags for the dataset"?
The current plan for the changeset tag contains "source_ref" already. So
this approach reduces complexity I think. What do you think of this?
Best regards,
2022年8月11日(木) 19:28 Marc_marc <marc_marc at mailo.com>:
> Hello,
>
> thanks for the time you spend on that.
>
> Le 11.08.22 à 11:52, Satoshi IIDA a écrit :
> > https://wiki.openstreetmap.org/wiki/MLIT_PLATEAU/imports_outline
>
> in the Schedule section, "2022/04 questionnaire for Japanese Mapper.
> Result: here" seems to have a missing link
>
> it's greet that the script is opensource !
>
> Tagging Plans : comment contain a lot of non-english stuff,
> I'm unable to understand those comments
>
> "by providing a ref tag for the objects, it simplifies the update
> process on the OSM side for future updates" : it's a dogma, a myth:
> if one day you make an upgrade, you will have to take into account
> the buildings without ref that the contributors will add. therefore
> if you script is able to manage the buildings without ref, the ref
> in osm has a very limited or even negative interest.
> add the ref in osm if this ref is used in the real world.
> don't add it if it's information for a script
>
> addr:full : I don't know about the address system in your country
> but isn't it possible to split addr:full into the more precise tags
> that exist? I think addr:full exists for cases where an addr doesn't
> fit in the general case (or as a temporary tag)
> another solution is to separate the import of buildings <> import
> of addr
>
> Tag merge : I don't like the idea of automatically overwriting
> the values in osm with the values from the import.
> The opendata contains sometimes errors, in case of conflict it is
> not necessary to overwrite but to treat that separately (to overwrite
> building=yes by a more precise value is obviously possible)
>
> Changeset Tags : add a good changeset description, for ex :
> importing building outline/height/levels/ele start_date/addr
>
> Regards,
> Marc
>
>
>
> _______________________________________________
> Imports mailing list
> Imports at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/imports
>
--
Satoshi IIDA
mail: nyampire at gmail.com
twitter: @nyampire
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/imports/attachments/20220812/2a24c4c4/attachment.htm>
More information about the Imports
mailing list