Question Google Maps module - coordinates rounding

Hi guys

I've a little question about how the Google Maps module manages the coordinates.
I know that the number of decimals may be set with the precision configuration option (where the default values are: Country: 0 digits, State: 1 digit, City: 2 digits, Neighborhood: 3 digits, House: 4 digits, Max: 9 digits), but I really don't understand why there's this function... Couldn't we save the coordinates as they are inserted by the users?

I think that the precision can be seen as an index of how large is an area, but this solution make me think about a few problems:

1) One degree in longitude near the equator is more than 110 Km, at the poles it is 0, so there's not a real indication of how large is an area.

2) The latitude degrees have a direct relationship with distance, the longitude ones no.

3) Some countries are really small (Vatican City is 0.01 degrees wide, Principality of Monaco is 0.03, San Marino is 0.1, Principality of Liechtenstein is 0.2, Andorra is 0.3, Malta is 0.4). Rounding the coordinates to the nearest integer is not very good in these cases.

4) And, last but not least, why there's this rounding functionality?

Couldn't we save the coordinates as they are inserted by the users?

Actually we do. The rounding is used when finding coordinates during the 'add new" process of the GM module, You can choose it identify a location as a City, State, Country etc, which then changes to rounding of the coordinates provided automatically (on search) by Google Maps before they are saved. But yes, it is equally possible to type the number of dec. places you want and save those.

Thank you for the response Nigel.

I'm surely missing something, but it still remains unclear for me this

The rounding is used when finding coordinates during the 'add new" process of the GM module

I mean, why does the 'add new' process round numbers?

I can't really answer any better, sorry. You might need to ask at Google Maps for the reasons. It is a feature of their API, that webtrees uses. I suspect it has less to do with ACTUAL lat/long than it has to the interpretation of lat/long required to pin-point a location in Google Maps. The two are not necessarily the same.

At the equator, where a degree of longitude is the largest:
Imagine you are looking at a map of whatever type of area, at the zoom level appropriate.

What part of a degree is the distance between two adjacent pixels?

What part of a degree is the precision of your mouse movements?

What part of a degree is the error in Google's positioning of the image data?

The last one is the biggest, I'll wager. But it's hard to be sure, because I have yet to find a location where my iPhone doesn't tell me the accuracy is "within 56 feet" (20 meters) or worse.

WGroleau wrote:

What part of a degree is the error in Google's positioning of the image data?

The last one is the biggest, I'll wager. But it's hard to be sure, because I have yet to find a location where my iPhone doesn't tell me the accuracy is "within 56 feet" (20 meters) or worse.

Well, I can tell something for northern Italy. Five years ago I created a website with many (more than 1,150 Km) trekking paths in the Alps.
Those paths came from various sources: mainly they came from personal knowledge of some tens of volunteers (and drawn over official Italian cartography based on Istituto Geografico Militare maps), but also from many GPS track logs (mine and from others volunteers).
Superimposing these path to Google Maps and Google Earth showed a high degree of accordance (errors under 5 meters), implying that Google did a great work.
Furthermore, Google Maps has satellite and aerial photographs that well suit the Tele Atlas maps (and Tele Atlas is used by car gps like Tom Tom).

By the way, I think that an even bigger question is what is the precision that webtrees users need?
I think it's surely lower than the precision of the Google Maps. And, furthermore, the precision needed by the users is dependent of the webtrees place level: at the Country level it's lower than that at the neighborhood level.
I think that Nigel introduced the precision based on decimal places to represent in some way these precision changes. But, as I discussed above, this solution isn't suitable for every case. Furthermore it seems to me that this precision is quite useless: besides saving a fixed number of decimal places, what is it used for?

I think that a better indicator of precision (in the sense related to place levels) would have been something like Show this place for zoom levels up to...: when a user is looking at the map with a zoom suitable for neighborhoods, is it correct to show Countries markers?
Anyway, this solution too is not that great. For Vatican City, for example, I would like to see its pin also at the highest zoom levels. Surely this is not the case for Russia...

A more correct solution would be to have a default maximum zoom level at which the places are visible, which is suitable for the most places at a specific level. When the users assign the coordinates to a place on the map, they could change the default value (for example setting it to the zoom level currently used to view the map).

I’ve seen GIS systems where property lines are VERY wrong compared to the aerial photos. But of course that doesn’t mean Google would have similar errors. However, I have also seen Google hybrids where the map street lines and trail lines are very far from the streets and trails in the photographs.

If Google is accurate, I think the current method of specifying a precision and zoom level for each defined level in the place hierarchy is good. Your idea, if I read you right, is to let each specific place have its own setting. That would indeed be an advantage, but would be a lot more code. Preserving those over GEDCOM export import would require the shared place mod and a custom tag.

WGroleau wrote:

I’ve seen GIS systems where property lines are VERY wrong compared to the aerial photos. But of course that doesn’t mean Google would have similar errors. However, I have also seen Google hybrids where the map street lines and trail lines are very far from the streets and trails in the photographs.

Is it possible to quantify this VERY? If it's up to 100 meters (for example) I don't think it's a great problem for webtrees usage. For greater values it may be a problem... Since I'm really interested in gis related things, do you remember a place where the we can see Google Maps misplacements?

WGroleau wrote:

If Google is accurate, I think the current method of specifying a precision and zoom level for each defined level in the place hierarchy is good. Your idea, if I read you right, is to let each specific place have its own setting.

Only in special cases. Let's assume, for example, that countries are visible for zoom levels up to 5. The users could keep this default value for almost any country: they should specify the max zoom level value only for special levels (12 for San Marino and 4 for Russia). And about the precision (intended as the number of decimals): I would remove it completely, since for me it is meaningless.

WGroleau wrote:

Preserving those over GEDCOM export import would require the shared place mod and a custom tag.

Three points about that:

• I've tried this:
  1. Import a GEDCOM with places without coordinates
  2. Import places from GEDCOM to webtrees
  3. Set the coordinates of the imported places
  4. Export the GEDCOM
  In the resulting GEDCOM there's no latitude/longitude values. So, I think that (at the moment) the webtrees tables of georeferenced places are used only to display Google Maps inside webtrees.
• There's already a zoom value that is not part of the GEDCOM 5.5.1 Specifications
• The webtrees parameters specific to place managements does not need to be stored inside the GEDCOM: they are stored in the webtrees tables and are associated to the place names. When the users do an export/import cycle, the places information is kept (as long as the webtrees database is the same).

WGroleau wrote:

Your idea, if I read you right

You read right. It's my written English that's not so great (and my spoked English is even worse)...