New Topic

Locus Map - help desk Topic Idea Locus Map (Android)

This object is in archive!

Category Locus Map (Android)

Comments 12

Subscribers 2

Votes 4

Alternate Datums

junkml@yahoo.com shared this idea ago

Completed

It would be great if you could include different datums, in particular NAD27 is of interest to me, as many of the topo maps in the US use that datum. Here`s a formula for WGS83 to NAD27: http://www.colorado.edu/geography/gcr...

And the gold-standard conversion too: http://www.ngs.noaa.gov/TOOLS/Nadcon/...

I like this idea 0

Replies (4)

elmuSSo ●

i dont belive he will do that, because in taht case all the maps should be converted on-the-fly to the new datum, and this would eat the whole processor. Grab your maps put them into mapc2mapc and convert them into SQLlitedb format. This is m way, you can also play with GlobalMapper .

URL

Starman ●

So if you entered Locus settings and selected one of the other six datums offered, wouldn`t that conversion take place "on-the-fly"? Presently, Oruxmaps offers a choice of 250 datums, and Oruxmaps would use the same processor on my phone as Locus does. Several of the datums that Locus offers, such as CH 1903 and Dutch Grid (RD), are fairly recent additions by user request. When requested, the reply was not, "convert your maps."

URL

elmuSSo ●

I`m sorry, that my bad. I misunderstood your request. I was thinking about rendering maps with use of differenct datum and projection.

URL

Menion ●

This idea is already implemented for some time.

To add own coordinate system, follow this manual

Such system are used "only" to display coordinates, not to reproject maps on-the-fly.

URL

Tom Grundy ●

Hello, The link you provide seems broken - can you provide an update or the actual instructions on how to change datum (which is not the same thing as coordinate system)? Thanks

URL

Menion ●

Sure, here it is http://docs.locusmap.eu/doku.php?id=manual:customization:custom_coordinate_systems

URL

Tom Grundy ●

Thanks for the quick response with the link. It's very handy to have EPSG capability in an android app for offline use! Looks like there might be a problem with the transformation though - would you be able to take a look and see if you agree?

Point in question: Castle Peak summit, Nevada County CA (there are three peaks in a line WNW to ESE; using the WNW peak as reference here)

datum=wgs84, coord system = DM.m (degrees and decimal minutes) (EPSG:4326)

39deg 21.972m N

120deg 21.105m W

datum=nad27 conus, coord system = UTM zone 10s (closest listed EPSG=26710)

(checked this with the golden reference, http://spatialreference.org/ref/epsg/nad27-utm-zone-10n

as well as Garmin Basecamp which is the same as the conversion algorithm inside garmin gps units,

this confirms that 26710 does use 'NAD27 CONUS' since there are other NAD27 sub-datums that actually are off by up to around 100m)

07 28 242 E, 43 60 568 N

However when I add this line to config_projections.cfg

1|26710|NAD27|NAD27|United States

I get these coordintes in Locus Pro for the Castle Peak summit:

728147.14m (E)

4360547.67m (N)

Do you see the same results? Hopefully I'm just missing something obvious.

Thanks

-Tom

URL

Tom Grundy ●

Hi, have you had any time to take a look at this? Thanks

URL

Menion ●

Hi Tom, please next time create an separate issue, otherwise I'll not correctly notice any changes in old, already completed topic.

I do not know how to help here as I'm not expect on coordinate systems.

I'm testing your projection on this page http://twcc.free.fr/ and here is result (screenshot). As you may see, it's again completely different result.

Locus currently use this definition

# NAD27 / UTM zone 10N

<26710> +proj=utm +zone=10 +ellps=clrk66 +datum=NAD27 +units=m +no_defs <>

So if this is correct, I have no idea how may I help here as Locus use Proj.4 library and not any own implementation for coordinate transformations.

Files:

URL

Tom Grundy ●

Thanks, I will investigate more with other sources and will open a new issue here if needed / if I discover any solid answer elsewhere. I understand that any calculation differences are apparently outside the scope of Locus. That's a very handy conversion website, I was looking for something like that. We're using the same proj4 code so the mystery remains.

-Tom

URL

Menion ●

Hmm same code for transformation and even quite different results? Interesting. I can't imagine, that change in Proj.4 version should have any influence. In Locus is currently Proj4 in version 4.7.0 if this helps.

URL

Tom Grundy ●

Hey thanks for the reply even if it's still the same thread. I opened a question on stackexchange, there have been some very knowledgable responses, sounds like something with the grid shift file and I am not familiar with how to remedy it? I was planning to ask on that stackexchange thread what the next step for me as an end user would be: ask you to see if you have the correct grid shift file on the host, or, me to download the correct grid shift file on the client, or, ?

Unless you know the correct answer to what the next step is, I will go ahead and ask that question on the stackexchange thread.

If you have time, could you please take a look at that thread here:

http://gis.stackexchange.com/questions/127905/conversion-differences-going-from-4326-to-26710

URL