Added `do_coordinates()` to `import_gedcom.py`
Jan 7, 2024 18:53:35 GMT -8
Post by Uncle Buddy on Jan 7, 2024 18:53:35 GMT -8
The LATI & LONG tags now work.
treebard.com/gedcom.html (my free book) seems to be missing a chapter called "A Place is Really Three Things". I'll see if I can find out where that chapter is hiding.
The strategy on LATI/LONG was to keep it simple. The GEDCOM specs expect us to re-import or re-export the same place over and over. Rather than fiddling around with trying to be better than GEDCOM--since saving GEDCOM from itself is not my problem--I just overwrite the coordinates for a given place if they're repeated. To improve this, a more complicated strategy would be to check whether the coordinates for a place are the same each time, but there are reasons to not bother. For example, it would slow down the import process.
Another reason to not bother is that several genieware vendors have created custom primary tags (_PLAC, _PLACE, _LOC) which are used on zero lines so coordinates don't have to be repeated every time a place is repeated. The real reason is that a place and its coordinates have a one-to-one relationship, so the coordinates belong in the primary record, but GEDCOM per specs has no primary record for places.
We don't do custom tags here at Treebard University, they are not our problem. We plan to get all custom tags except obvious vendor cruft into exception reports, if we live long enough.
treebard.com/gedcom.html (my free book) seems to be missing a chapter called "A Place is Really Three Things". I'll see if I can find out where that chapter is hiding.
The strategy on LATI/LONG was to keep it simple. The GEDCOM specs expect us to re-import or re-export the same place over and over. Rather than fiddling around with trying to be better than GEDCOM--since saving GEDCOM from itself is not my problem--I just overwrite the coordinates for a given place if they're repeated. To improve this, a more complicated strategy would be to check whether the coordinates for a place are the same each time, but there are reasons to not bother. For example, it would slow down the import process.
Another reason to not bother is that several genieware vendors have created custom primary tags (_PLAC, _PLACE, _LOC) which are used on zero lines so coordinates don't have to be repeated every time a place is repeated. The real reason is that a place and its coordinates have a one-to-one relationship, so the coordinates belong in the primary record, but GEDCOM per specs has no primary record for places.
We don't do custom tags here at Treebard University, they are not our problem. We plan to get all custom tags except obvious vendor cruft into exception reports, if we live long enough.