<div dir="ltr"><div>Hi Anders,</div><div><br></div>Hmm...others may have better suggestions, but in my opinion, this sounds like an Organized Editing activity. You can read more about it here: <a href="https://wiki.osmfoundation.org/wiki/Organised_Editing_Guidelines">https://wiki.osmfoundation.org/wiki/Organised_Editing_Guidelines</a><div><br></div><div>Best,</div><div>Iyan</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Mar 25, 2021 at 5:28 PM Anders Torger <<a href="mailto:anders@torger.se">anders@torger.se</a>> wrote:<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>
I have a question about formalities around manual imports, specifically <br>
when an import user account is required.<br>
<br>
The Swedish NVDB import which we look at formalizing now is generally <br>
not to cover new ground, ~90% of roads already exist, but to refresh <br>
existing geometry and enrich/update tags and correct the many positional <br>
errors that exist, and of course be able to say that 100% of our <br>
nationally documented roads also exist in OSM with just as good <br>
precision.<br>
<br>
A script exists to convert NVDB shape files to an OSM layer. No <br>
automation exist for actually getting it into the OSM database though, <br>
that's a normal JOSM workflow, and includes several manual steps to <br>
adjust certain things in the script-converted layers that the NVDB data <br>
can't get right, mainly the OSM highway type and bridges/tunnels, but <br>
also adding things like turning circles and fixing quirks that may <br>
appear in naming.<br>
<br>
While the external database provides road geometry, quite often more <br>
modifications is done to existing nature and buildings as these often <br>
have considerable alignment errors and need to be realigned to match <br>
correctly aligned roads. All this is done manually of course.<br>
<br>
The work-intensive merging process with many adjustment of new and old <br>
means that compared to mapping work where you nowadays typically trace <br>
the NVDB roads by hand from the raster layer (which exits pre-loaded in <br>
JOSM and has better positional alignment than available aerials) the <br>
speed is about 5 - 10 times faster with better precision. Change sets <br>
become the same as with manual mapping, ie multiple small areas that <br>
come at a slow rate. Personally I would do about 100 - 200 road segments <br>
per changeset, and 1 - 5 changesets per day, which means 15 - 30 days <br>
for a normal sized municipality (there are 290 municipalities in <br>
Sweden). While I sometimes do mapping marathons with a high number of <br>
changesets per day, if I would do everything myself it would still take <br>
about 10 - 15 years to go through Sweden.<br>
<br>
The import aspect of it is tags like maxspeed, access restrictions, <br>
oneway etc which you can't see on aerials or the raster representation.<br>
<br>
While the import process needs formal approval, I still don't really see <br>
this process as a typical import, but rather a way to speed up what is <br>
already done manually (there are several examples of Swedish mappers <br>
using NVDB data on their own already to speed up their personal mapping, <br>
and this is already widely accepted).<br>
<br>
What I wanted to get to is that I don't see the need to use a specific <br>
import user for this type of work. It's so manual, and it's so <br>
intertwined and overlapping with normal maintenance work, and the NVDB <br>
geometry already exist in raster form in JOSM and is widely used even by <br>
casual iD mappers. What do you think?<br>
<br>
/Anders<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>