Expansion on adding new places

[mother10]

Thinking about adding New Places, I want to propose a new feature.

As far as I know it has been mentioned already some time ago, so its in fact not my idea.
But that was before, or around the time,  Ancestris 13 was released and there was no time to do that.

Hopefully now there is time.

Proposel:
When adding a new place, the map defaults to some unknown place in the ocean near France (why France?      ), with a zoomfactor that does not help in figuring out (quickly) where that is.

Would it be possible to choose a default depending on some information in a users GEDCOM?
Like for instance the country of the submitter?

If this could work, together with what is mentioned by Bernth here: https://forum.ancestris.org/index.php?topic=5178.0  that would be great!
Then you can quickly shift the marker to where you want it.

Tineke

[Zurga]

Again, where is the trouble : you have a special editor to search the location on internet and get the coordinates quickly.
The default position is done to be sure that you won't think it is a correct value.

Anyway, I will search for a way to allow users to define default values.

Zurga

[mother10]

Hi Zurga,

That would be great!!!
Thanks.

Tineke

[Zurga]

Done.
You will see it in tomorrow version.
New parameter in the Data option panel.

Zurga

[mother10]

Hopefully I dont make anyone angry now as I am already very happy with the possibility to add default coords.

So I hardly dare to ask, but I looked in the committed code and saw coords added, but no zoomfactor added.
Would that be possible too, or am I asking too much now?  

That would be so great.

Thanks,
Tineke

 

[ebea]

I think the easiest way is to right-click on the overview map and scroll to your location, although moving the arrow would have been easier.
I have given up on the arrow.

The problem is that when you enter an address with a city name, possibly a county, and a country, the map will still show a location outside of France, and not the location based on the entered address, as you suggest. The country in question could be the trigger for placing the map.

Open Street Maps has the function of popping up the map, after a location is entered.

[Zurga]

The problem is that when you enter an address with a city name, possibly a county, and a country, the map will still show a location outside of France, and not the location based on the entered address, as you suggest. The country in question could be the trigger for placing the map.

Open Street Maps has the function of popping up the map, after a location is entered.

I still don't understand.
You click on the search button in the place editor, the map move automatically to the first result.

Zurga

[ebea]

Maybe we're talking past each other a bit.

I think when I wrote as I did, that by entering in the editor, with e.g. place of birth (City, County, country), the location in the country in question could be captured, so when you clicked on the little Globe to bring up the map, the location (Country) was already there on the map.

When I use your suggested search, it's a bit of double work, because the location doesn't hit correctly when searching, and longitude and latitude don't fit into the 2 boxes.
And then you still have to move the location on the map (the double work).

You only get the location correctly by using the method you suggested, by maneuvering with the map, and right-clicking on the map, whereby the coordinates are inserted into the 2 boxes.
And this is where the frustration arises, because you start every time, off the coast of France, when a new person's data needs to be placed.

[mother10]

Hi all,

I experimented a bit. Using "Koegras" as an example.
Thats a very old "place" that is not used (does not exist) anymore today.
Did that on purpose to see what Openstreetmap would do.

I start with an event that has nothing assigned yet, so no date no place no nothing.
And the tree has no "Koegras" anywhere for another event either.
I use the Cygnus editor. And fill in just "Koegras" in the placebox. (no province no country)
Then I click the globe.
The screen opens with "Koegras" in the Place box, the pointer in the sea near France, and "Koegras" in the city box.
The coords are still wrong and point to the sea near France.

Now all I do is press the "Search"-button.
The map jumps to our province North Holland and the pointer is on the "polder" Koegras. (so the area not the place as that does not exist.)
In the Internet list it then shows Koegras with the info present in Openstreetmap.

Now I could rightclick on the blue pointer and I can choose to have the coords of that position in the boxes.

I must admit I stil have trouble with the buttons "Replace" and "Complete".
But thats not the subject here.

So this is what happens on my side.

Dont know if this helps a bit, I hope it does.

Tineke

[Zurga]

I think when I wrote as I did, that by entering in the editor, with e.g. place of birth (City, County, country), the location in the country in question could be captured, so when you clicked on the little Globe to bring up the map, the location (Country) was already there on the map.

Each search impact the Geonames API credit.
From our point of view, it is better to let the user choose when launch this request.
The location is already in the search field with the exact texte written by the user.

When I use your suggested search, it's a bit of double work, because the location doesn't hit correctly when searching, and longitude and latitude don't fit into the 2 boxes.
And then you still have to move the location on the map (the double work).

To my understanding, if the search doesn't find any place, make a first search or not doesn't change anything.

You only get the location correctly by using the method you suggested, by maneuvering with the map, and right-clicking on the map, whereby the coordinates are inserted into the 2 boxes.
And this is where the frustration arises, because you start every time, off the coast of France, when a new person's data needs to be placed.

You can write the coordinates directly in the boxes.
And I think that the last update prevent the frustration.

Zurga

[ebea]

As written in #5 - I give up on this, with the pointer. It ruins my day, to try more of this.

Zurga, you get it as you want it!

[mother10]

Tested the new coordinate feature.
Some remarks:

1:
When I change the values on the preferences screen, somehow Ancestris does not let me logically save them. I can press OK on that screen, but the save button in the main toolbar stayes grayed.

When I close the tree there is no warning either. So it looks like OK on the preferences screen has not the same meaning to Ancestris as OK on other screens.

When i add a change anywhere else, on another screen (after OK on the new coords), I get a warning when I close without saving, but the new coord values still are not saved.
Only when I click apply on the preferences screen, they are saved.
Thats a bit odd as on other screens OK means things are put in the tree, and Ancestris marks the warning if you dont save.

2:
The text "Default coordinates" is not in bold, like "Pictures", and everything is shifted to the right instead of neatly below the other groups on the left.

The word "Latitude" is given as "Latitu...", so it looks as if it does not fit in the label itself.

3:
The boxes for the coord values should be way longer, as now you dont see the whole value.

4:
The boxes dont have a hint explaining what they are for.

5: when I open the mapwindow from the globe, the map is at the correct place now, and the coords are in their respective boxes.
But when the coord values are long like 52.372900590240995, they dont fit in the boxes on the mapscreen.
(these long values are a direct copy from Google, they are given there with that many characters behind the comma, so it would seem logical to be able to see all those characters.)
Hopefully those boxes can be made longer too.

Would it be possible to correct these things?

Thanks for the work.

Mother10.

[Zurga]

1 => Preferences are for the all application, not a specific GEDCOM file, so the behavior described is perfectly correct.
This is the same for all preferences.

2 => Default coordinates are not a type of preferences, they are placed under the "text" element.
So no bold and correctly aligned.
I will check the size of the box, it fits correctly with a 12 size font.

3 => I don't see the usefulness of a coordinates with lot of digits by default.
Since there is no limit for a coordinate, how long do you think this field should be ? 20 ? 30 ? 100 digits ?

4 => OK

5 => Again, a coordinate as not digit limit. I'm not sure that there is a real difference to place a point at the millimeter.
5 digits after the comma gives you a 5 meter precision.
With your 16 digits precision, you give a picometer precision.
Not sure this is mandatory.

Zurga

[mother10]

1:
If thats the case the OK button can go from that screen.
Change the text of the Apply button to SAVE.
Thats way more logicall for a user then.

2:
Take into account the translation.
In Dutch that would be "Noorderbreedte" and "Zuiderbreedte", thats way longer that what is possible now.
In other languages it may be even longer.

3: and 5:
No preferences? What are they doing on the Preferences screen then.
Boxes should be able to contain the whole number of characters from Google, as thats often used if a place cannot be found in  Openstreetmap.
And that happened a lot in my tree as those very old places often are not found in Openstreetmap.

General remark. As a lot of older people have problems witb their sight, at least some bigger fonts should not make boxes and or labels "overflow".
Same for translations, what might be a short word in English or French and fit in a box or label, might turn out a long word in another language.

Mother10

[mother10]

After testing the latest update from 2025-01-06:

Point 2: Labels now fit.

Point 3 and Point 5: Coordinate precision of places in Ancestris. (Latitude and Longitude)

The following is only meant for those who later read this thread:

According to ChatGPT it is as follows, using Amsterdam as an example:

Coordinates of Amsterdam according to Google:  [52.372900590240995, 4.893293380737305]
Coordinates on the preferences screen: [52.372902    and   4.8932934}
  ChatGPT: difference is 0,16 meter, so 16 cm.
Coordinates on the Map screen, where you search and enter new places info: {52.3729 and 4.89329}
  ChatGPT: difference is 0,25 meter, so 25 cm.

As you can see Ancestris does not round the original long values. No ideaa what it does with them.
But now you might understand why the marker you might put somewhere, might move a bit.
As Zurga already said, the difference is minimal.

And for the mathematicians among us:
Python code used by ChatGPT:

Code: [Select]

# Constants
import math

# Coordinates with original precision and saved precision
original_coords = (52.372900590240995, 4.893293380737305)
saved_coords = (52.372902, 4.8932934)

# Earth's radius in meters
earth_radius = 6371000

# Function to calculate the distance between two lat/long coordinates
def haversine(coord1, coord2):
    lat1, lon1 = map(math.radians, coord1)
    lat2, lon2 = map(math.radians, coord2)
    dlat = lat2 - lat1
    dlon = lon2 - lon1
    a = math.sin(dlat / 2)**2 + math.cos(lat1) * math.cos(lat2) * math.sin(dlon / 2)**2
    c = 2 * math.atan2(math.sqrt(a), math.sqrt(1 - a))
    return earth_radius * c

# Calculate the distance
distance = haversine(original_coords, saved_coords)
distance


Which gave a result of:  0.1567635034994744 meters.

(With "way longer" I did not mean "drown".) 

Point 4: The hints.
They work, but small thing in the Hint: Latitude has a capital L, longitude a small l.

Mother10