<div dir="ltr"><div><br></div><div>Hello Marc,<br><br>Thank you for the feedback!<br><br>> <a href="https://wiki.openstreetmap.org/wiki/MLIT_PLATEAU/imports_outline">https://wiki.openstreetmap.org/wiki/MLIT_PLATEAU/imports_outline</a><br>> Schedule section, questionnaire Result: here" have a missing link<br>Ouch, I missed it!<br><br>> Tagging Plans : comment contain a lot of non-english stuff,<br>> I'm unable to understand those comments<br>Also, I've added the translation lines. Could you check those?<br><a href="https://wiki.openstreetmap.org/wiki/MLIT_PLATEAU/imports_outline#Data_Preparation">https://wiki.openstreetmap.org/wiki/MLIT_PLATEAU/imports_outline#Data_Preparation</a><br><br>> "by providing a ref tag for the objects, it simplifies the update<br>> process on the OSM side for future updates" : it's a dogma, a myth:<br>> don't add it if it's information for a script<br>OK, I see. I'll remove it. (and also remove the "for future updates" line)<br><br>> addr:full : I don't know about the address system in your country<br>> but isn't it possible to split addr:full into the more precise tags<br>> that exist? I think addr:full exists for cases where an addr doesn't<br>> fit in the general case (or as a temporary tag)<br>> another solution is to separate the import of buildings <> import of addr<br><br>We have 2 issues regarding this task.<br>1. Very few objects have this value in raw data.<br>2. We have no parser for this separation.<br>Japanese community had a long, long discussion about updating addr:* structure.<br>And it is almost solved recently. So we have no parsers yet.<br>I'm going to ask the team if we can have a separate plan as you suggest.<br><br>> Tag merge : I don't like the idea of automatically overwriting the values in osm with the values from the import.<br>Yes, this is also mentioned in the local discussion. I agree with you, but I think this has fewer impacts.<br><br>1. This is "semi-"automatically. It needs checks by an importer during the workflow.<br>2. 99.9% of Plateau objects do not have the specific building:* value...<br><br>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!".<br>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.<br>So the conflict would be quite rare, and we can find it in the import workflow process.<br><br>> Changeset Tags : add a good changeset description, for ex :importing building outline/height/levels/ele/start_date/addr<br>Thank you!<br>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 <a href="https://gic-plateau.s3.ap-northeast-1.amazonaws.com/2020/attributedata.xlsx">https://gic-plateau.s3.ap-northeast-1.amazonaws.com/2020/attributedata.xlsx</a>)<br>And even each changeset has different target tags. This approach might be slightly complex for importer and checker both.<br><br>So how about making a wiki page for listing "target tags for the dataset"?<br>The current plan for the changeset tag contains "source_ref" already. So this approach reduces complexity I think. What do you think of this?<br><br>Best regards,<br><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">2022年8月11日(木) 19:28 Marc_marc <<a href="mailto:marc_marc@mailo.com">marc_marc@mailo.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello,<br>
<br>
thanks for the time you spend on that.<br>
<br>
Le 11.08.22 à 11:52, Satoshi IIDA a écrit :<br>
> <a href="https://wiki.openstreetmap.org/wiki/MLIT_PLATEAU/imports_outline" rel="noreferrer" target="_blank">https://wiki.openstreetmap.org/wiki/MLIT_PLATEAU/imports_outline</a> <br>
<br>
in the Schedule section, "2022/04 questionnaire for Japanese Mapper. <br>
Result: here" seems to have a missing link<br>
<br>
it's greet that the script is opensource !<br>
<br>
Tagging Plans : comment contain a lot of non-english stuff,<br>
I'm unable to understand those comments<br>
<br>
"by providing a ref tag for the objects, it simplifies the update <br>
process on the OSM side for future updates" : it's a dogma, a myth:<br>
if one day you make an upgrade, you will have to take into account<br>
the buildings without ref that the contributors will add. therefore<br>
if you script is able to manage the buildings without ref, the ref<br>
in osm has a very limited or even negative interest.<br>
add the ref in osm if this ref is used in the real world.<br>
don't add it if it's information for a script<br>
<br>
addr:full : I don't know about the address system in your country<br>
but isn't it possible to split addr:full into the more precise tags<br>
that exist? I think addr:full exists for cases where an addr doesn't<br>
fit in the general case (or as a temporary tag)<br>
another solution is to separate the import of buildings <> import<br>
of addr<br>
<br>
Tag merge : I don't like the idea of automatically overwriting<br>
the values in osm with the values from the import.<br>
The opendata contains sometimes errors, in case of conflict it is<br>
not necessary to overwrite but to treat that separately (to overwrite <br>
building=yes by a more precise value is obviously possible)<br>
<br>
Changeset Tags : add a good changeset description, for ex :<br>
importing building outline/height/levels/ele start_date/addr<br>
<br>
Regards,<br>
Marc<br>
<br>
<br>
<br>
_______________________________________________<br>
Imports mailing list<br>
<a href="mailto:Imports@openstreetmap.org" target="_blank">Imports@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/imports" rel="noreferrer" target="_blank">https://lists.openstreetmap.org/listinfo/imports</a><br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature">Satoshi IIDA<br>mail: <a href="mailto:nyampire@gmail.com" target="_blank">nyampire@gmail.com</a><br>twitter: @nyampire</div>