Missing Place List entries for Indis V3Alpha
Brought to you by:
canajun2eh,
yalnifj
Menu
▾
▴
Many of my family members were born in Helsinki, Finland. I do not see anyone under Helsinki, Finland in MelizaPAF.GED. I see only another box with Tervakoski. (One sample individual is I003)
(I have encountered similar problems with missing letters or family names in the Individual list)
How can I take a look at this issue? Do you have a PGV website that you have been using for testing that I can check this out on?
Well, I found the error, so maybe I can just describe it for you. It was a GEDCOM error, and I don't know that there was anything you could do about it.
The reported place name was Salt Lake Utah.
I searched the GEDCOM and found two instances of Salt Lake. Ut (period instead of comma)
I edited them online to commas. (My first editing work. Kudos!)
I think it is reasonable that the parser parsed those names as one place. What might be a possible avenue of improvement is dealing with the period (a special php character, right?) The period wasn't reported, so when I asked for a list of records connecting to that place, the period wasn't included in the search and therefore nothing was found.
There was a "Salt Lake\. Utah" place in the GEDCOM.
There was no "Salt Lake Utah" place.
BUG FIX OPPORTUNITY. Make phpGedView track, report, and search on periods in place names such as
Mt. St. Helens, Miss., U.S.A.
Would that name have trouble too because of the periods? Hmm.
Now that you identified it why don't you file it as an RFE. This will allow for it to properly be tracked. At the worst the RFE will be closed without fixing.
Maybe I should test more and see if it is a bug. If phpGedView fails to treat place names properly when they have a period, wouldn't that be a bug?
In testing a little more, I hypothesize
That phpGedView is treating properly periods in place names IF they are followed by a comma,
That this is explicitly done in the code somewhere,
And that periods between alpha characters or followed by a space are tripping phpGedView up for some reason.
Here is a GEDCOM that trips it up:
2 PLAC Olifantshoek, Cape Col., S.Africa
Here is another:
2 PLAC Salt Lake City, Salt Lake. Utah
And another:
2 PLAC of Mt. Pleasant, Ulster, NY
But this works fine:
2 PLAC Mesa, Maricopa., Ariz Terr.
Isn't that rather a bug?
On this subject, is it harmonious with the vision of the place list to eventually allow clicking on a place name and thus getting a list of the records that refer to that place? I found some errant place names, but no way of knowing whence they came.
Eden,
I emailed you details. Hope the spam filter lets it through. Have fun bug hunting.
Meliza,
I took a look and when I selected Helsinki, Finland from the place list I saw the message '1 Place connection found, view results now' in addition to another place box 'Tervakoski'. When I select the message I see individuals and familys that have places of Helsinki, Finland. Is this what you were seeing also? If so it might just be a little confusing that the message needs to be clicked to see the results.
Hmm. When I click on the 2 place connections shown, view results now, it does.......nothing.
http://www.hawsedc.com/phpGedView/placelist.php?action=show&level=1&parent\[0]=Salt+Lake+Utah
in the R W Shumway and P C Legg gedcom.
Tom Haws
Just for clarification are you running 2.65.3 or 3.0 alpha ?
I, hawstom, who am not getting any list of whence the place names come, am running 2.65.3.
I was wondering why the version doesn't show next to the phpGedView icon in the footer.
I see you are running 2.65.3, this would need to be tried again once you go to 3.0 to see if it is still an issue because there were some fixes/changes to the placelist in V3.0.
Is 3.0 generally recommended at this point?
Hi Thomas,
NO, version 3.0 is NOT recommended. This version is still alpha !!!
Now that is out of the way, you can see the version of your installation when you hover the mouse over the PGV icon at the bottom.
As for the placelist, it works this way:
1. Click Place Hierarchy
2. Click on the desired location
3. Then, if there are more locations beneath it, it will show in the box just underneath it
4. if there are more locations, click on the location and a new box will appear with names of people in that place.
4. If there are no more locations, the names of people will be shown immediately.
5. Click on a name to go to the individual.
If you see x number of place connections, you can click on that link to get a list of people that are all connected to that place. For example place a has subplaces place b and place c. Clicking on place a gives you option place b and place c. Clicking on place b will you give you those people. Clicking on place c will get you the people of place c. Before getting there and being at place a, you will see x number of place connections found. Clicking on that link, will you give you the people from place b and c in one box.
I hope I explained it clear enough, otherwise, just ask :)
Regards,
Roland
Beautiful description. Thanks for taking the time. Your description is as I imagined it should work. It turns out that this place name Salt Lake Utah is just not working. Other place names are working. I will check my GEDCOM.
(Add to FAQ)
Eden thanks.
I have been testing and testing PGV but did not realise that this is the way to see the individuals.
I expected to see the list of people and the lower level box without additional clicking.
I did not understand the meaning of the place connection message.
Hi Thomas,
I am working on the placelist sorting, actually all soritng issues :).
I have followed the thread and understand the problem. Can you send me a clippings file with some of these placenames? I can then just import and see the issue and solve it :)
The reason I am asking for the clippings file is merely to make my life easier :D
You can send it to botak at users dot sourceforge dot net.
Thanks.
Regards,
Roland
P.s. you can make a clippings file with PGV.
Hello all,
Here is a solution to the place mystery. Places are deducted by comma seperation. So this means it is imported like this: City, County, State/Province, Country. All periods are removed.
This explains it all. Whether we should change this, I don't think we can. Looking at several different gedcoms, all places are seperated by comma's as the period is used for abbreviation. Here is the description of the GEDCOM 5.5 standard:
This shows the jurisdictional entities that are named in a sequence from the lowest to the highest jurisdiction. The jurisdictions are separated by commas, and any jurisdiction's name that is missing is still accounted for by a comma.
More info on the standard: http://www.gendex.com/gedcom55/55gcch2.htm
All that is left to do I guess, is to adjust the offending GEDCOM record.
Regards,
Roland
We should NOT change PGV to accommodate periods as field delimiters. Such errors are GEDCOM errors and are the user's responsiibity.
We SHOULD change PGV to be consistent about period treatment. Here's the problem: PGV is removing the period at some point, and then comparing the stripped string with a string that still has the period intact. Note that Mt. St. Helens, Wa. will not turn up any place connections because of this.
What do you think?
I dont think that the . is invalid as long as there is a ,
So, the problem
Is with dot space
Is not with dot comma
May not be with dot alphanum
p.s. I can only verify that this is a problem for dot space. Dot being dropped from "@/./s" alphanum dot space import. I am not sure if it is being dropped from "@/.@" alphanum dot alphanum import.
In genealogy you shouldn't use abbreviations anyway when you enter in places.
The reason why the periods were stripped in the first place is that if abbreviations are used you want the program to recognize AZ. Az. AZ Az az and aZ all as the same place. The easiest thing to do is to ignore periods completely.
So do we want to change policy and say that AZ. is not the same place as AZ and leave all periods in tact?
--John
Your logic makes sense. I think it is a question for genealogists.
as mentioned by hawstom is Mt. St. Helens, Miss., U.S.A. invalid?