Improved locations (boundaries instead of pin points)

Ideas
1

I think it would be nice if Gramps locations / maps could support GML / GeoJson / WKT geometries instead of only simple longitude / latitude points.
E.g. for an event with the place Australia it would look a lot better to mark whole Australia on the map instead of a single point in a desert somewhere in the middle of Australia.
(In a perfect world there would also be a tool allowing you to draw place borders directly on the map.)

2 Likes
2

See Adding places from KML [Keyhole Markup Language] files in case that helps.

1 Like
3

I like the idea that a place like Australia - or more modestly a city - is represented by a KML representing its surface rather than by a simple GPS coordinate of the center of this place. GPS coordinates are adapted to a singular point like an address in a city while the KML is rather better for the city itself.

Apart from the fact that obtaining the KML is a little less simple, other questions will arise in Gramps. For filters for example.

Some allow comparisons around GPS coordinates by searching for this value in other places but as far as I know it does not look at whether all or part of what is being searched is included in the surface represented by the KML (if it is a KML representing a surface, which is not necessarily always the case, it can represent a path that may or may not be within the perimeter around the search point). It would therefore probably take a lot of adaptations to use either GPS coordinates or a KML to represent a place indistinctly in Gramps.

And yet I suppose I am only seeing the tip of the iceberg.

4

I have started to add an Internet link to Place records. I am doing this using Google Maps. To facilitate this, I modified the standard Google map link to ignore any existing GPS in the record and instead to open the link with the KML map (if it exists) and made it an addon.

Just added it to my Gramps addons on GitHub

1 Like
5

Once upon a time I worked with spatial data. Within spatial data you have 3 data types: points, lines (represented by 2 points) and areas or polygons (represented by a series of points). With these data types it is possible to make a large number of calculations, e.g. distance, size etc, but also more advanced like nearest-neighbour, contained-within, crossing and so on.
I can see several use cases for spatial data, but I think it will be a tremendous job to implement, even with different Python spatial libraries available.
And to make the iceberg even bigger - there’s a variant of spatial data called spatio-temporal, where a time data is added to the spatial data.

2 Likes
6

Now we’re talking! I am new to Gramps, noticed the ‘pins in the desert’, and immediately started to investigate how to incorporate border highlighting by KML in my “place data” hierarchy. I sail, and I use an open-source chart plotting project and stumbled across a collection of historic maps that were anchored to Geo-coordinates. Since all charts come with a warning; “do not rely solely on ___ for navigation” i substituted these old maps on my chart plotter to give my passengers and crew a bit of a thrill by letting them believe that was how i got them across the water! My next thought, since my tree has now reached back to pre-revolutionary times here in the United States, was: “How cool would it be to not only show the daguerreotype of 3XGreat Gramps… but also how the map looked, at the time, for the place he was born!” The collection of maps I have wouldn’t cover every possible point in time, but close counts in horseshoes :wink:
I’m keeping my eyes open for this fork to ‘get underway’!

1 Like
7

Perhaps it can be added in steps. First an update to the datebase so it can store different types + a backward compatible function that always returns it as lat + long (either from a single point or a geometry center) + a new function that returns the geometry. Then other parts could either implement support for it or keep using lat + long.