Could we use the files from RGEalti IGN ? about pyhgtmap HOT 17 CLOSED

I found my answers to get there you have to look at this GitHub.

roelderickx/ogr2osm#46

Thank you so much for helping me

from pyhgtmap.

I've just read that Sonny takes RGEAlti files, so I'll have to test it with his latest update to see if it's better.

from pyhgtmap.

Hi, and thanks for your interested in pyhgtmap :). I'm French as well but will stick to English to ease sharing with other people.

Here is what I've found on ASC format:

• https://surferhelp.goldensoftware.com/subsys/subsys_ASC_Arc_Info_ASCII_Grid.htm
• https://en.wikipedia.org/wiki/Esri_grid

And here is the header of a RGE Alti 1m .ASC file:

ncols        1000
nrows        1000
xllcorner    1021999.500000000000
yllcorner    6293000.500000000000
cellsize     1.000000000000
NODATA_value  -99999.00
 327.69 327.64 327.56 327.54 327.40 ...

So this file covers a 1000mx1000m square.

On the other hand, HGT format always covers a full 1°x1° (lon/lat) square, whatever its resolution. The bigger the file, the better the resolution. For eg. 1" HGT files contains 3 times as many point per dimension as 3" HGT files (3601 square side vs. 1201).

• https://cs108.epfl.ch/archive/17/p/04_elevation-profile.html
• http://fileformats.archiveteam.org/wiki/HGT

So if you can convert a set of RGE ASC alti files into huge HGT files, pyhgtmap should handle them (to be tested; I think resolution is computed automatically from file size, but I didn't check everywhere).
But beware, computation will be much longer, and output probably much bigger as well!

Supporting natively ASC files would probably require a deeper refactoring of pyhgtmap, as it would need to break the "each tile is a 1°x1° one" assumption.

from pyhgtmap.

I've just read that Sonny takes RGEAlti files, so I'll have to test it with his latest update to see if it's better.

Indeed, but from the datasources file, he seems to rely on the 5m one (which is anyway down scaled to 30m for 1" HGT format):

FRANCE (incl. Monaco, Guernsey, Jersey)
########################################

- Institut national de l’information géographique et forestière (IGN): RGE ALTI, DTM 5 m
https://geoservices.ign.fr/rgealti

- Métropole Bordeaux: DTM 0.5m
https://data.bordeaux-metropole.fr/data.php

- NASA: SRTM Version 3.0 Global 1" DTMs
https://dwtkns.com/srtm30m/

from pyhgtmap.

Thank you very much for your time., that's what I'm trying to figure out.
When we talk about 30m it means that we have points every 30m in x right?

For the moment I'm going to test with Sonny because the border management will be complicated too from what I've understood on the forums.

from pyhgtmap.

When we talk about 30m it means that we have points every 30m in x right?

Yes.

from pyhgtmap.

Ok, so the hgt is not very precise. Do you know of another format that converts to an .osm that would be a little more accurate for smoother curves?

from pyhgtmap.

It's not the HGT itself. It's only the default ones (3" and 1"). You could use HGT format with a 1m precision (so 1mx1m square for each point), but you would end up with a file 900 times bigger than an HGT 1" file (so about 22.5GB for a single tile).

from pyhgtmap.

Thank you very much for all your answers. It may not be what I'm looking for as it's for a map Garmin.
I'll try with the new Sonny files + the smooth of your program maybe it will be already very good.

from pyhgtmap.

I tried with the new files but nothing exceptional, it's more the smooth=2 that brings something better but here's how to succeed and it's maybe not feasible to manage to smooth like on IGN's Scan25?

from pyhgtmap.

I think you're rather looking for "--simplifyContoursEpsilon" option if you want to have simpler contour lines.

from pyhgtmap.

I don't think so, because on hills, for example, they become polygons, almost squares, whereas they should be egg-shaped.

from pyhgtmap.

I think it's the smoothing algo that's done afterwards because in red is my contour line and in violet is the one with 5M RGEAlti data and the background is the IGN map.

from pyhgtmap.

I've found the data I need and they're already processed.

https://geoservices.ign.fr/courbes-de-niveau

The question is, do you know how to convert .shp files to .osm?

This image shows in red the .shp curve data and in blue the curve data from the hgt files.

It can be seen that the curves in red are those used by the ign for their Plan or scan 25 rendering.

from pyhgtmap.

For your information : https://github.com/roelderickx/ogr2osm

converts the file, but for the moment the tags are no good and are not processed by mkgmap.

from pyhgtmap.

Thanks for sharing your findings.

from pyhgtmap.

My conclusions for the moment for one department the weight of the card is almost the same but the rendering is much better in any case I find.
With the IGN contour data, you can see that they are the same as the Plan rendering.

With Sonny's hgt file

I'm launching the whole creation for France this weekend I think, I'll come back to say if it's acceptable.

WARNING for the moment I don't know how to manage France + a border country.

from pyhgtmap.