[Talk-it-piemonte] Mappa Del Piemonte per GPS Garmin

[Kay F. Jahnke]

Dear list, please indulge my slightly off-topic posting, which isn't 
strictly speaking an OSM matter.

Am 08.03.2017 um 23:08 schrieb stefano campus:

> this is the direct link to Regione Piemonte "BDTRE - Database GeoTopografico
> - 2017" metadata, 2017 edition
>
> http://www.geoportale.piemonte.it/geonetworkrp/srv/ita/metadata.show?id=6467&currTab=rndt

Thank you for the link! Looking at the data I find that the difference 
to my rendition is indeed not very large. From a sample I compared I 
found that my contours seem to have less high-frequency noise (erratic 
small jagged features), which is probably due to using a different 
process of creating the contours, maybe involving slight smoothing. This 
is visible in the shapefiles - on the GPS unit with it's limited 
resolution (somewhere around 3m accuracy) the difference is probably not 
visible, but coming from smoother data before quantizing is usually a 
good idea to avoid artifacts.

Creating the contours from the DTM is, in a way, the easiest part. 
Coming from the DEM, I made two sets of contours, one set with the 
multiples of 20m (to produce a 'light' version which I haven't 
published), and one with the 10, 30, 50, 70 and 90 contour lines to go 
in between. The CTRN-OSM-GPS uses both together, providing the same 
level of detail as the BDTRE contours.

The CTRN-OSM-GPS map follows the original section codes (019, 020, 035, 
036, 051...) of the CTRN (and CTR) map, and all layers of my map use 
this scheme. In my experiments, I found that this amount of sections 
plays well with my GPS unit - the smaller-scale subdivisions into 
sixteenths of the larger sections (019160, 020090, 020100...) produces 
so many tiles that the GPS unit has a hard time handling them - in fact 
I could not build a functioning map working with the subdivisions, this 
is why I have the aggregation step in my scripts which aggregate the 
subsections into the larger ones.

In producing the contour tiles, I wanted the same section boundaries 
which are used throughout the remainder of my map. To have clean 
borders, I rendered the contours for the whole territory in one go, then 
cut the result into the sections. This way, all layers are divided the 
same way, avoiding overlap, and they cover rectangular areas. The BDTRE 
data are - AFAICT - cut by region boundaries, so to use the BDTRE data 
in rectangular tiles, one would need to join and recut the data.

Now, with the rectangular tiles at hand, the most time-consuming part is 
the conversion to garmin image format via ogr2osm.py and mkgmap; these 
tools aren't particularly fast.

 >
 > forse il lavoro di contour a partire dal dtm non era così necessario.
 >

Maybe going all the way is not 'necessary', but I like having as much 
control of the process as I can, and there is a lot more involved than 
just creating the contours. Keeping all this in mind I will stick with 
my own contour-generation process and go all the way from the DEM, which 
I use anyway (as a VRT file over the GeoTIFF version of the DEM) to show 
hillshades or gradient colouring in qmapshack.

Let me conclude in expressing my delight at the availability of these 
data! I wish I could get more of this kind. While I haven't investigated 
further east, I also found a similar level of detail for Liguria, which 
was a great help in creating a detailed GPS map for my hike on the GTA 
from Ventimiglia to Domodossola in 2015. One area where - when I last 
looked - the DEM is still not freely available, is VdA, which forces 
producers of free maps to fall back onto SRTM or ASTER based data. The 
same can also be said for Switzerland, where the freely available DTM is 
at 100m resolution (again, when I last looked...), so clearly inedequate 
for pedestrians, which is surprisingly meagre considering the level of 
detail of topo map everyone can freely look at via their version of geo 
portal.

So, thumbs up, Piemonte! Carry on with the good work.

With regards
Kay F. Jahnke