AlpineQuest & OfflineMaps

Posted: **Thu Apr 05, 2018 8:10 pm**

Support for ozf2 and especially for ozf3 formats elevated Alpine on new level because many people have tons of such maps. But projection support seems quite limited. When I recalibrated map to wgs84 or Pulkovo projection they worked fine, but for Hermannskogel datum Alpine displays error message about not supported projection, or something like that. It eventually load map, i guess using default (wgs84) datum, but then of course everything is shifted. Do you plan to add more datums, or even better something like custom_ozi_datums.cfg where datum translations will be described

Posted: **Fri Apr 06, 2018 5:25 pm**

Hi,

The application supports most common projections used by OZF maps (Mercator, Transverse Mercator, Universal Transverse Mercator and Lambert Conformal Conic). It also handle a lot of datums (155 in total), but it's true that you cannot use your own datums.

I'll publish a beta version tonight which will use datums from the application if the map datum is not found among "ozf" datums. This way you'll be able to import/use your own datums (since you can already import datum in the application).

Best regards

Posted: **Fri Apr 06, 2018 10:25 pm**

Psyberia-Support wrote: ↑Fri Apr 06, 2018 5:25 pm Hi,

The application supports most common projections used by OZF maps (Mercator, Transverse Mercator, Universal Transverse Mercator and Lambert Conformal Conic). It also handle a lot of datums (155 in total), but it's true that you cannot use your own datums.

Great. Then probably Hermannskogel datum (widely used in former Yugoslavia states and I guess Austria) is just differently named (projection is ordinary Transverse Mercator). I tried with "HKG","MGI 1901", but no success. (There are many definitions of Hermannskogel datum)

Psyberia-Support wrote: ↑Fri Apr 06, 2018 5:25 pm I'll publish a beta version tonight which will use datums from the application if the map datum is not found among "ozf" datums. This way you'll be able to import/use your own datums (since you can already import datum in the application).

Marvelous!!! I will use that for sure, because even Ozi definition of Hermannskogel is not great (3 parameter, instead of 7). And of course, even 155 definitions can not enough, but with using imported datums/projections AQ can deal with even exotic ones.
Still, will be good to make Hermannskogel working out of box, because average user don't know/want to deal with datums and projections.

Many thanks for looking into this!

Posted: **Sat Apr 07, 2018 8:05 am**

Hi again,

I've published the beta yesterday evening. Let me know when (if) you get it so I can help you with this datum (but "MGI 1901" should be recognized). Next official version should be released within one or two weeks.

Note that if you calibrate new maps yourself, the datum is not important to make a precise calibration. What's important is the map projection. The datum only adds a shift to the image (at least for OZI maps which use a 3 parameters transformation; 3-axis translation) which you counterpart by the calibration.

Posted: **Tue Apr 10, 2018 1:49 pm**

Hi,

I can't get Hermannskogel to work. AQ display no datum is found. I don't see attachment option on forum controls so I will just paste content of my cs file:

Code: Select all

PROJCS["Hermannskogel",GEOGCS["Hermannskogel",DATUM["Hermannskogel",SPHEROID["Bessel 1841",6377397.155,299.1528128,AUTHORITY["EPSG","7004"]],TOWGS84[682,-203,480,0,0,0,0],AUTHORITY["EPSG","6312"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.0174532925199433,AUTHORITY["EPSG","9108"]],AUTHORITY["EPSG","4312"]],UNIT["metre",1,AUTHORITY["EPSG","9001"]],PROJECTION["Transverse_Mercator"],PARAMETER["latitude_of_origin",0],PARAMETER["central_meridian",21],PARAMETER["scale_factor",0.9999],PARAMETER["false_easting",7500000],PARAMETER["false_northing",0],AUTHORITY["EPSG","31277"],AXIS["Y",EAST],AXIS["X",NORTH]]

As you can see projection is also defined here, but i guess that is not necessary, because my maps use ordinary transverse mercator.

PS
MGI 1901 works[not ideally, but not AQ fault], but this is built in, I guess

Posted: **Tue Apr 10, 2018 3:11 pm**

Ok thanks.

It's actually not the same than MGI 1901.

I've attached the file you've to put in the "[app folder]/cache/cs/" folder to be able to use it. Be sure to restart the application. See here how to locate the application folder.

You'll see a new "Hermannskogel" location format in the settings, under "Location format". Version 2.0.10 beta can also use it for OZF maps.

Let me know if you have any issue.

Edit: the correct EPSG name and code for your CRS is "[MGI 1901 / Balkans zone 7]" (EPSG:3909), and not EPSG:31277.

Posted: **Tue Apr 10, 2018 5:59 pm**

Hi,

Thanks,

Interesting ... Your file [sort of] works if file is named exactly as datum in map file. So, Hermannskogel.cs works, but Hermannskogel_blah_blah.cs does not. For displaying coordinates name of file is irrelevant.

Why sort of? Because although map is loaded map view is shifted about 7000km away . I found it only because I have waypoint in that area. But AQ grid is perfectly aligned with printed grid on map, so map is correctly georeferenced

I can upload somewhere map if you need to see it.

Posted: **Wed Apr 11, 2018 10:42 am**

Yes if would be great if I can have access to the map.

Concerning your comment on the file name, this is the wanted behavior.
In fact, the file name is used as the internal ID of this CRS (which is not displayed to the user, where instead, a display name is used, found in the file content). So to be found by the OZF map loader, it must have the same ID.

Posted: **Wed Apr 11, 2018 12:31 pm**

Maybe subfolder within cs/ folder called "ozi_datums/"? I'm fine with existing solution, but it will be more intuitive for users. As of now, it is a hard to distinguish between location formats used for displaying coordinates and those for supporting ozi datums.
BTW, AQ have by large best system of displaying coordinates

https://drive.google.com/file/d/1kF3849 ... sp=sharing

Map area is in East Serbia, in the case you must hunt it, too

Posted: **Wed Apr 11, 2018 1:22 pm**

Thanks for the map file!
It's much easier.

So here is a working file, just replace the previous one.

Concerning the handling of datums, I like the fact that the same ones are used for both (display to user and OZF maps). This way you can check all the results you get. You just have to keep in mind that the datum name used in the OZF map must be the same that the file name (if not already built-in).

I think that the problem here came from the understanding of what is exactly the "Hermannskogel" datum. In this case it's "MGI 1901" (code "EPSG:3906"). In the .map file, if you replace "Hermannskogel" by "MGI 1901", it will work fine without adding any .cs file (in version 2.0.10 beta).

I'll soon publish a new version in which I've included new location formats for Balkans.
Anyway, I'm happy if you like the app,
Best regards!

Posted: **Wed Apr 11, 2018 3:49 pm**

Thanks,

Now works fine! At first map view was also 7000km away, but after I (using waypoint) got correct area into view, on subsequent run it works perfectly. I guess this was problem with internal cache, if such exists for offline maps.

Although native support for Hermannskogel would be fine, bonus with custom datums is even better:

Differences between WGS84 and Hermannskogel (and probably many other datums, I know for sure Pulkovo 1942 is the same in that regard) are not systematic. So any datum is just rough conversion between wgs and such datums. In practice, if some one want accurate maps, then the only way is using custom datum. National geographic authorities publish (in my country they require payment for that

) local datums for small area in which local datum is accurate within cm's ,if not mm's]. For comparison, attached Hermannskogel have average error 5-15m, and even much more accurate 7-parameter conversion can be off by 5m [average 1m]. But such datums are only valid for small area, 100 square km or so.
So if some want accurate connection between gps position and map [in national datum] there is only one way - using local datums, and for that, your solution is God send!!!.

For years I have hoped to see good gps program for handheld devices. Till today I still mostly used Ozi for Android, because it supports ozi maps

. But from now on, I know which app will be my main program

Again, many,many thanks

Posted: **Wed Apr 11, 2018 4:12 pm**

Thanks for your support!

You're absolutely right, you can find various conversion parameters for the same datum based on the area in question.
Most of the time you don't get much differences, so it's fine for a leisure app to only use one set of parameters per datum, but it's true that if you need more precision you need to deal with different parameters...

Right now, for "MGI 1901", the application uses:

Code: Select all

TOWGS84[476.080,125.947,417.810,4.610862,2.388137,-11.942335,9.896638]

But during my researches (for Slovenia area) I've found various different ones:

Code: Select all

// http://www.asprs.org/a/resources/grids/10-2011-Republic-of-Slovenia.pdf
//  -> TOWGS84[426.9,142.6,460.1,4.91,4.49,-12.42,17.1]
// https://epsg.io/31276-1786
//  -> TOWGS84[426.9,142.6,460.1,4.91,4.49,-12.42,17.1]
// http://www.transformacije.si/sl/clanki/d48-d96/7p-trans/pvt
//  -> TOWGS84[476.080,125.947,417.810,4.610862,2.388137,-11.942335,9.896638]
//  = FEW CM DIFF
// http://prostor2.gov.si/ows2-m-pub/ows?SERVICE=WMS&L&VERSION=1.3&REQUEST=GetCapabilities
//  -> TOWGS84[551.7,162.9,467.9,6.04,1.96,-11.38,-4.82]
//  = FEW METERS DIFF
// https://epsg.io/3906
//  -> TOWGS84[682,-203,480,0,0,0,0]
//  = FEW CM DIFF
// http://spatial-analyst.net/wiki/index.php?title=MGI_/_Balkans_coordinate_systems (different values based on area)
//  -> TOWGS84[550.499,164.116,475.142,5.80967,2.07902,-11.62386,5.541764]
//  -> TOWGS84[574.027,170.175,401.545,4.88786,-0.66524,-13.24673,6.88933]
//  = EXACT SAME RESULTS

Posted: **Wed Apr 11, 2018 8:35 pm**

Forget "MGI 1901"

If possible, ie if names are not hard coded in library, if you use library for dealing with datums/projections, use name "Hermannskogel" because:
1. Ozi don't know what is MGI 1901 [(just tried with Ozi for PC)
2. Nobody, except people deeply in geo stuff, don't that too

Acceptable parameters are:
a. -> TOWGS84[682,-203,480,0,0,0,0] ' recommended by USA spatial agency and also by Serbian military geodetic authority for 3 parameter conversion
b.-> TOWGS84[574.027,170.175,401.545,4.88786,-0.66524,-13.24673,6.88933] 'official parameters from Serbian geodetic institute (I think Slovenian authority also recommends this). I personally use these values
c. Ozi values:653,-212,449

BTW, what will happen if datum is built in but user have custom definition of it? Which will have precedence?

And one suggestion for displaying coordinates, important when AQ finaly supports maps in different datums/projections. Will be nice touch.
Make option for primary and second location format "as in loaded map". Off course for (all?) online maps it will be wgs84/WebMercator, for sqlite maps, too. Don't know if AQ native format supports datums/projections. This format is even default in Ozi .

Posted: **Fri Apr 13, 2018 4:54 pm**

Hi again,

Forget "MGI 1901"

Ok!

BTW, what will happen if datum is built in but user have custom definition of it? Which will have precedence?

The application will first look at imported/user datums, and if nothing found it will use built-in values. Doing so it allows users to override any built-in value if needed.

Make option for primary and second location format "as in loaded map".

Interesting. I'll have a look at that.

Best regards

AlpineQuest & OfflineMaps

[closed] Ozi maps projections/datums

[closed] Ozi maps projections/datums

Re: Ozi maps projections/datums

Re: Ozi maps projections/datums

Re: Ozi maps projections/datums

Re: Ozi maps projections/datums

Re: Ozi maps projections/datums

Re: Ozi maps projections/datums

Re: Ozi maps projections/datums

Re: Ozi maps projections/datums

Re: Ozi maps projections/datums

Re: Ozi maps projections/datums

Re: Ozi maps projections/datums

Re: Ozi maps projections/datums

Re: Ozi maps projections/datums