[Imports] robot to fix most peak elevation

[Gregory]

Can your robot also send a message to the user that added the elevation
originally? The message can then teach them how to correctly enter
elevation so they don't continue making mistakes.

On 25 October 2012 22:44, Mayeul Kauffmann <mayeul.kauffmann at free.fr> wrote:

> Hi,
> Not sure it is the correct list (not an import, but the closest I
> found).
> About 1500 peaks have formatting errors in the elevation 'ele' tag (or
> have elevation stored in the 'name' tag).
> Most of these errors could be corrected easily.
> For example: expicit metric unit, unit is feet (and is written).
> REference (zero level) is given.
> Since there are many different kind of errors, I found that manually
> making a table with corrections and notes on harder-to-solve problems
> could be faster (and less dangerous) than writing a robot.
> Still a robot would be needed to update the value.
>
> The reference issue is not solved yet in OSM guidelines AFAIK, see:
> http://wiki.openstreetmap.org/wiki/Talk:Key:ele#Geodetic_datum
> A fix would be to put the original value in a note or comment, and drop
> the "above sea level" note (in whichever language it is).
>
> In addition to cleaning the database, one objective is to improve the
> way the ShowMeHills Augmented Reality Viewer shows the summits, see:
> http://www.showmehills.com/
> (ShowMeHills is GPL v3).
> I'm working with the author of showmehills on that; I made him discover
> OSM and we already imported part of OSM peak data in his app.
>
> Here is what I did so far:
>
> First I produced planet-121017-peaks_unit_fixed.csv
> Available at: http://outdoormaps.org/ftp/
> ##################
> cd ~/OSM/temp
>  # Download and build in one run: osmconvert  and  osmfilter
> wget -O - http://m.m.i24.cc/osmconvert.c | cc -x c - -lz -O3 -o
> osmconvert
> chmod a+x ./osmconvert
> wget -O - http://m.m.i24.cc/osmfilter.c |cc -x c - -O3 -o osmfilter
> chmod a+x ./osmfilter
> areaname="planet-121017"
> # It might be possible that a very few number of summits are stored as
> areas (closed ways) or relations, but dropping ways and relations gives
> a performance boost
> ./osmconvert --drop-author --drop-ways --drop-relations
> $areaname.osm.pbf -o=$areaname.o5m
> ./osmfilter $areaname.o5m --keep="natural=peak" > $areaname-peaks.osm
> # --all-to-nodes is not necessary below if ways and relations are
> dropped above; still should not hurt
>  ./osmconvert $areaname-peaks.osm --all-to-nodes --csv="@id @lon @lat
> name ele"  --csv-headline > $areaname-peaks.csv
> cat $areaname-peaks.csv | sed -e 's/m$//g' | sed -e 's/ $//g' >
> $areaname-peaks_unit_fixed.csv
> ##################
> Then I manually inspected the results, trying to classify the errors and
> fixing some of them. Result is on the same server as above, filename:
> planet-121017-peaks_unit_fixed_2.ods
> I've put an "x' in the "update_with_ele_draft" where I believe it is
> safe to replace the value "ele_original" by "ele_draft".
>
> I've never written a robot for OSM yet, so any comment, pointer or
> contributor wanting to write it is welcome.
>
> Cheers,
> Mayeul
>
>
>
>
> _______________________________________________
> Imports mailing list
> Imports at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/imports
>



-- 
Gregory
osm at livingwithdragons.com
http://www.livingwithdragons.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/imports/attachments/20121026/93265fdd/attachment.html>