PLACE structure

2008-10-07
2013-05-30
  • How feasible is it to provide a PLACE Record rather than a PLACE Tag, especially for the google maps module? In GEDCOM terms this would be called up and defined as a @Pnnnnn@ record.
    The idea is essentially to allow time frames, sources and notes to be attached to Places and for them to be called up by an index reference rather than by string matching. In reality, places frequently change names, administrative affiliations and even location as population growth occurs. Also there is often considerable uncertainty about historical locations.
    I suspect that such a change would speed up the google maps module and reduce the frequency of editing errors which I find to be quite a plague for a large active site.
    For generating a GEDCOM file, options could be provided for a standards compliant file when you want to exchange information with others and a PGV compliant file when you want to backup or do some batch editing.
    Graham

     
    • John Finlay
      John Finlay
      2008-10-07

      This has come up many times and there is a GEDCOM extension for it called GEDCOM EL.  I don't think that any other programs actually support it. 

      In summary, what it comes down to is we would like to move in this direction but we need a developer willing to take it on.  We currently don't have a developer with the time to tackle that project (and I think it would be a pretty big project).

      --John

       
    • Stuart.G
      Stuart.G
      2008-10-07

      I also would like to see the ability to add additional data related to locations/towns/churches/buildings/cemeteries etc.  I understand John's comments regarding the size of the project if it was to be developed fully. But could an interim step be made that would not be such a big project.

      I have been wanting something like this for many years. Other genealogy programs allow additional data to be added to locations. But as we know, this cannot be currently transferred in a compliant Gedcom file.

      Within PGV I have - stretched - the definition of SOUR and I have used this to add additional data about places/churches/cemeteries etc. SOUR allows you to add all of the additional data I would like to add; notes, media and other sources etc.

      Unfortunately I know nothing about PHP or MySQL, I therefore ask, would it be such a big job, as an interim measure, to replicate what is now available for SOUR and create a similar database for places. As Graham suggests, the cross reference link could be @Pxxxxx@.

      Also, as Graham suggests, when exporting the Gedcom file, we could have the ability to not export this tag, just like we do with other PGV specific tags.

      I would really like to see something like this implemented. This would really make PGV the cream of the crop!!

      Stuart

       
    • John Finlay
      John Finlay
      2008-10-07

      Adding support to the DB and GEDCOM is the easy part.  PGV is extremely flexible at the data model level.  The "big project" part would be all the UI features that would need to be implemented.  At the minimum, you would need to add a page that shows the details of those new level 0 PLAC records.  You would need a way to show how places are interrelated, and then all of the editing and internationalization features that would go along with it.

      I wonder if it wouldn't be better to use an external tool such as a wiki for places and just link to it using the textual place?

      Those interested in more consistency in entering places will enjoy the new autocompletion features added to the latest SVN.

      --John

       
      • Stuart.G
        Stuart.G
        2008-10-07

        Thanks John for your thoughts. Your explanation certainly takes away my thoughts about an easy interim step. I will just have to continue to stretch the definition of SOUR.

        I have tried the WIKI variation and other similar variations. But I am not that well organised. It means that I have to drop my work in PGV and go and add a WIKI entry, then come back to PGV and add the URL. Then, of course, after several months I cannot remember what WIKIS I have written and if I can remember that I have written one, I then have to go searching for its URL. Using SOUR will have to suffice until I get a bit more organised.

        Thanks to all for your good work.  Looking forward to installing V4.1.6.

        Stuart

         
    • Wes Groleau
      Wes Groleau
      2008-10-11

      What if output of GEDCOM automatically replaced 2 PLAC @L5@ with the contents of L5 ?

      Still doesn't address the editing of places, but would it be hard to modify a copy of the REPO code to handle the bare minimum of PLAC record editing?  And then over time, that could be integrated with the maps and other existing geography-related code.

      A big question though, is what to do on import.  Config option to create 0 PLAC records?  I already think that would be a good thing for SOURces.  But then we'd need ways to prevent duplicates, and to merge records that would have been duplicates if formatted/spelled the same.

      Indeed, a big challenge, but I think something useful could be put in and then improved.

       
    • Veit
      Veit
      2008-10-19

      The place structure is a difficult topic I had to learn.

      In Germany there some projects running to find solutions on it. The most interesting is GOV - the genealogical gazeteer http://gov.genealogy.net/. This is a place structure mostly regarding to the today and past german territory, repecting changing political, religious and cultural boundaries.

      On this there is a suggestion to enhance the gedcom standard (called GEDCOM 5.5EL found here http://wiki-en.genealogy.net/wiki/Gedcom_5.5EL\).

      Veit

       
    • mawsth
      mawsth
      2008-10-21

      I have got gigabytes of place data.. the reference to  old names  is made through a common gps location, and an alias table then it doesn't really matter, the geography and buildings are the same, and within the same timespan so are the people.. so where is the problem - the gedcom standard is "just another alias"
      that is "substituted" in if you want to output a "real gedcom"

       
    • Stew Stronski
      Stew Stronski
      2008-10-22

      Personally I don't see the need to try and "fix" this issue. The gedcom place specification is already somewhat broken, i.e the requirement for city, county, state, country when a lot of places around the world just don't use 4 levels in a meaningful way. Most of us with ancestors in England, Scotland, Canada, etc. use only 3 levels and just don't worry about the 4th. Trying to make the place spec fit every possible complication just adds confusion.

      For making PGV show original and modern place names: that's what the Note is for. I pick a consistent name for each place and stick with it. If the place no longer exists on any maps (common in Western Canada and other countries), I use the Note to put in an explanation and use the google maps module to show where it used to be. In this case there is no actual modern place to tie it to anyway. Having a system in place so that you can automatically show that someone born in xxxxx would today have been born in a field 7 kilometres west of town yyyyy just isn't useful. And for places we don't know any closer than the birth place listed in a census return it isn't terribly useful to have an exact modern equivalent of the general area either. London, London, England, United Kingdom is certainly no more exact than the London, Middlesex, England we see so often.

      Genealogy is about people, not places. But that's just my opinion :)

       
      • Greg Roach
        Greg Roach
        2008-10-22

        <<The gedcom place specification is already somewhat broken, i.e the requirement for city, county, state, country when a lot of places around the world just don't use 4 levels in a meaningful way. Most of us with ancestors in England, Scotland, Canada, etc. use only 3 levels and just don't worry about the 4th.>>

        Actually, the gedcom spec allows arbitrary and mixed place hierarchies.  To do this, use the FORM tag.  e.g.

        1 CHR
        2 PLAC Wisbech St Mary, Cambridgeshire, England
        3 FORM Parish, County, Country

        Each PLAC can have its own FORM.

        If a PLAC doesn't have a FORM, the default value (specified in the header) is assumed.

         
        • Stew Stronski
          Stew Stronski
          2008-10-23

          I'll stick with somewhat broken. The FORM tag is there but it isn't exactly easy to use. The ability to specify that the bottom of the 3 levels given is a parish or registration district and not a county or town  is a potentially very useful ability but the potential is kind of wasted. Does any application actually support using it without editing the gedcom by hand?

          Any feature is only as useful as the ability to use it. But I'm just a dilettante so it's probably a lot less important to me than it is to others.

           
  • Greg Roach
    Greg Roach
    2009-10-09

    @ kfnordan (I can't reply by mail, as your host rejected the connection from gmail).  My reply was:

    &gt; In one of your comments you said that:
    &gt; 2 PLAC Wisbech St Mary, Cambridgeshire, England
    &gt; 3 FORM Parish, County, Country
    &gt;
    &gt; Each PLAC can have its own FORM.
    &gt;
    &gt; Can you confirm that this is true,  I also have a FORM tag
    &gt; in the 0 HEAD also.

    Here is the relevant section from the gedcom specification:

    PLACE_STRUCTURE:=
    n PLAC &lt;PLACE_NAME&gt; {1:1} p.58
    +1 FORM &lt;PLACE_HIERARCHY&gt; {0:1} p.58
    +1 FONE &lt;PLACE_PHONETIC_VARIATION&gt; {0:M} p.59
    +2 TYPE &lt;PHONETIC_TYPE&gt; {1:1} p.57
    +1 ROMN &lt;PLACE_ROMANIZED_VARIATION&gt; {0:M} p.59
    +2 TYPE &lt;ROMANIZED_TYPE&gt; {1:1} p.61
    +1 MAP {0:1}
    +2 LATI &lt;PLACE_LATITUDE&gt; {1:1} p.58
    +2 LONG &lt;PLACE_LONGITUDE&gt; {1:1} p.58
    +1 &lt;&lt;NOTE_STRUCTURE&gt;&gt; {0:M} p.37

    As far as I know, there is no application that uses or generates
    these tags, so PGV has never needed to support them.

    (SInce FORM can be used for different things, it would need
    some special code - as you have discovered)

    Place handing in the gedcom spec is pretty poor/restrictive.

    I was proposing a way to enhance it, while keeping within
    the spec.

     
  • Mark Hattam
    Mark Hattam
    2009-10-09

    GEDitCOM is one application where you can add FORM to each and every PLAC if you desire … together with subordinate NOTE and SOUR.

    Personally I see little point, but it is there and available.

     
  • knorway
    knorway
    2009-10-11

    (fish) Thanks for the update.  I'm trying hard to fix my PLAC cards (records) in my GEDCOM file.  I've just started to fix (by hand) over a 1000 poorly entered PLAC records from another software product (mostly my fault but some caused by poor software design) before implementing my first PGV.  For now I'm testing with a USB stick and don't have a real web presence.  I was hoping to be a little lazy and use a FORM record under each PLAC to force a different display so I could move forward.  My goal is to use GoogleMaps and have some level of consistent PLACes.

    Back when I started using GEDCOM based software (12 years ago) I never thought that a formatted PLAC was too important as long as it got me to where I wanted it to go.  But now I see it just like I've always see dates (define the stored date structure and convert it to a user centric date display) and things will be better.

    Thanks again and if anyone has any ideas about how to clean up my PLAC cards let me know.

     
  • kiwi_pgv
    kiwi_pgv
    2009-10-11

    I always recommend two tools:

    1 - PGV itself. The Batch Update - Search and Replace option is a very effective way to tidy up a lot of place names. Batch Update is on the Admin page.

    2 - For an off-line alternative, try GEDPlace.exe , from http://www.rootsweb.ancestry.com/~gumby/ged.html .  Its simple and free. It displays all your unique GEDCOM places in alpha order, and allows in-place edits. Really easy to use, and doesn't touch any other part of your file, so very safe to simply re-import to PGV when you're done.

    You're not at all unusual in finding a need to do this as soon as you want to use the GM module. The good news is that its a one-time job, generally, and well worth the effort.

     
  • knorway
    knorway
    2009-10-12

    Thanks Kiwi.  I'll look into both options.

     
  • knorway
    knorway
    2009-10-14

    One note about GEDPlace.exe.  This only works with an ANSI based file so if your GED is in UTF-8 (and you use UTF-8 characters) you may need to open it in something like NOTEPAD then save it as an ANSI file, then convert it back later to UTF-8 (I think!) when done.

    Point Of Interest:  (IMHO)

    I for one would like to see eventually the inclusion of a FORM card under the PLAC card.  So locations (places) that are defined differently in different countries (states in the US, counties in Ireland, fylkes in Norway …) can be displayed more accurately or where a level is not always use (like city in rural areas, or the inclusion of township).  The FORM card would allow a smoother entry of data for these situations (a selector switch here for predefined formats would be good).  The FORM card would also help readers (months/years later) understand the structure and names.  It would also help when I'm forced to leave out ( use a blank level) and later try to find a location in GoogleMaps.  I realize that reports displaying places would need to look for the FORM card for each place before displaying the result to get the display right, so this is not a simple change. 

    A NOTE card would also be go here to help explain the place information and also deal with historical changes for the name reorganizations that almost every European nation has gone thru (i.e.  combining/dividing of cities, townships, counties …) so future readers can see and understand that the histories of locations are living/breathing entities too.

    I'm very new with PGV and I know that this topic has been talked about a lot (sorry).  It's not a deal breaker.  Wish I was a PHP programmer and understood the layout/design of PGV so I could help.  Great job on a great program and project, thanks to everyone.

     
  • Greg Roach
    Greg Roach
    2009-10-14

    Adding a FORM under a PLAC is trivial.  Go to your gedcom config page, and look for the &quot;Advance PLAC facts&quot; setting.  Add FORM there.

    You can add any fact you like.  If it is not one known to PGV (in languages/factarray.en.php), then you should add it to languages.extra.en.php.  If you add a new fact, you'll also need to add help text for it - just another entry in extra.en.php.

    But - the gedcom spec uses FORM for two different things.  Media format (jpeg, bmp, avi, etc.) as well as PLAC format.

    Since PGV currently only uses this tag in the media context, the editor assumes that is what you want, and provides an editor customised towards editing media types.

    I've just submitted a quick code change to SVN to stop this.

    With this, you can edit/save/store PLAC:FORM fields.  Nothing currently uses them, and they are not displayed anywhere.  But you can enter it, and if it is there, it may get used in future.

     
  • knorway
    knorway
    2009-10-14

    Thanks. 

    And hopefully someday expanding PLAC to a level 0 will get some play (for shared places).  And too, a smart individual can build an object that uses a PLAC:FORM card to display the place data/titles dynamically, so the intervening empty levels can be removed, title differently or new levels can be added. (for example):

    where FORM cards could be:&lt;br&gt;
    FORM place, township, county, state, country&lt;br&gt;
    FORM place, city, county, state, country&lt;br&gt;
    FORM place, kommune, fylke, country&lt;br&gt;

    Normally in the last one I'd have an empty level: PLAC place, , kommune, fylke, country

    Then the expanded display would take on these values as titles just like the display takes on the titles from the HEAD:PLAC:FORM does now.

    Thanks again

     
  • kiwi_pgv
    kiwi_pgv
    2009-10-14

    Regarding :

    *One note about GEDPlace.exe. This only works with an ANSI based file so if your GED is in UTF-8 (and you use UTF-8 characters) you may need to open it in something like NOTEPAD then save it as an ANSI file, then convert it back later to UTF-8 (I think!) when done.*

    I use it regularly with utf8 files, and have had no problems.  You may be right about utf8 characters though, as I don't have any (or at least none that have yet casued a problem).

    You don't need to do any fancy conversion either. Downloading your GEDCOM from PGV includes an option to save in ANSI, and re-import will convert it back.

     
  • knorway
    knorway
    2009-10-14

    Yes you are correct, it is only the non-English characters like the Norwegian ø å æ that I have trouble with.  The rest show fine.  The same thing happens when I try to use MS-Access and read in the GED, a quick change to ANSI using NOTEPAD and things are good with MS-Access.  As a wet behind the ear, first time PGV user I've only imported small bits to see how the file import works and the extended capabilities over prior PC based products.  I like the better use of the GEDCOM schema and media capabilities.  Thanks for the tip on exporting/importing ANSI, I'll use that with my MS-Access reports.

     
  • Wes Groleau
    Wes Groleau
    2009-10-15

    Does GEDPlace assume ASCII, or is it eight-bit?

    If eight-bit, it should not choke on UTF-8  It will just display them weird, and they will be hard to edit, but if not edited, they will still be the correct haracters when saved.

     
  • knorway
    knorway
    2009-10-15

    It does not choke.   Just displays as two chars. 

    Entering new data is kind of odd also because it is expecting the entering person to key in the &quot;two chars&quot; not the normal single key stroke. 

    I'm trying to tell people (and not doing a good job, sorry) that if they have a UTF-8 file and have non-english chars (Norwegian, Swedish, German, Polish …) they will freak out that the data has two abnormal crazy letters (on the mainframe we called it a double byte char) in place of the normal crazy (just kidding) letters.  Users may think they can't use the program.  They can use the program, the file just needs to be saved as ANSI.

    You are probably correct (however I have not tried this) also to say that if you don't edit the record or need to add the letters to a record the file will correctly have the correct letters save in the file.