<div dir="ltr"><div>In fact you should seize this opportunity to remove those (extremely long) source tags which came from the cadastre import. No need to keep dragging them along, they will forever be in the history of the buildings.<br><br></div>Polyglot<br></div><div class="gmail_extra"><br><div class="gmail_quote">2015-04-19 18:56 GMT+02:00 Serge Wroclawski <span dir="ltr"><<a href="mailto:emacsen@gmail.com" target="_blank">emacsen@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'm very excited to see more information being applied to the Paris<br>
building data, and I think we'll want to look at the technique in<br>
general to see where it could be applied to other imports.<br>
<span class=""><br>
>> Can you explain why you want a source tag instead of including the<br>
>> information in the changeset?<br>
><br>
> Because it's more explicit, no need to look into changesets relative to a<br>
> building to check if its building:levels tag has been updated from<br>
> OpenDataParis or not. But if it's better to put it into the changeset<br>
> instead of inside each updated element, ok it's not a problem...<br>
<br>
</span>Here's why I think source on changesets is better:<br>
<br>
We can imagine this same question of "What is the source?" being<br>
applied to every tag.<br>
<br>
But then we extend it further- "When was this tag made?" and "By whom?"<br>
<br>
Suddenly we are capturing so much metadata per tag...<br>
<br>
Putting the source on the changeset solves this.<br>
<br>
That's why it's generally the preferred method now a days.<br>
<br>
- Serge<br>
<br>
_______________________________________________<br>
Imports mailing list<br>
<a href="mailto:Imports@openstreetmap.org">Imports@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/imports" target="_blank">https://lists.openstreetmap.org/listinfo/imports</a><br>
</blockquote></div><br></div>