Return to Project-GC

Welcome to Project-GC Q&A. Ask questions and get answers from other Project-GC users.

If you get a good answer, click the checkbox on the left to select it as the best answer.

Upvote answers or questions that have helped you.

If you don't get clear answers, edit your question to make it clearer.

county names in virtual GPS GPX files disagree with GSAK conventions

0 votes

The virtual gps feature on exports GPX files that introduce atleast one quirk into my gsak databases. This post is to ask for the best way to fix it and if there are any others.

The one oddity that I noticed was the county field gets filled out with odd content. For locations in the US, instead of the County name it is "Countyname County (State Abbreviation)" As an example, "Orange" becomes "Orange County (NY)". Similiar things appear to happen in other countries as well. "Hobart" in Australia becomes "Hobart ©(6)". While fine for human consumption it is causing counties to be miscounted in challenge macros.

Is there a way to align the GSAK names with the project-gc names for the counties inside  (Related question is what does use?)
asked May 25, 2016 in Support and help by sloth96 (3,490 points)
Just had a look - I agree, the county names you mention are not correct in Project GC. Looks like all county names in Australia and US are incorrect (bracketed items should be removed, however I am not sure if the correct county name for Orange is "Orange" or "Orange County"). This is something that needs Ganja to fix. Can anyone identify other countries that have incorrect county names?
Singapore names are also incorrect. They should be "Central Region", "East Region", "North Region", "North-East region" and "West Region". However the boundaries do not match those in PGC, so something is not right somewhere.


Try this:
I can answer the bit about what uses: they don't have county names at all.

1 Answer

0 votes
Our county data will differ from GSAK in almost all countries, for different reasons. The products will update the polygon data in different points in time, meaning that one might have newer data than the other. I can't speak for GSAK, but Project-GC always strive to have as accurate data as possible, regardless of how many vertex points the polygons are. Having polygons with very many vertices makes them slower to work with, but that is not a problem for us at least.

But, handling polygon data takes a lot of time. Especially to produce new polygons and update the data. It requires a good data source, understanding of the data, and's country divisions. Sometimes we get help from the community with the data, and I am sure GSAK does as well. This is another case where we will not end up with the same data.

Project-GC's most common data source for this kind of data is OpenStreetMap.

Regarding if there is county or not in the name; We use the tiger data as our source for USA, we use the names that they use.

The state abbreviation has been added to remove conflicts of the same county name over several states. It makes it easier for users and it fixes some of our design issues in the code where we over and over again have assume that county names are unique within a country. A similar case exist for Australia.

If your issue is GSAK, I suggest importing into a separate database and then run a macro that fixes counties on all of them. When the counties are "fixed" to be compatible with GSAK, merge the databases.
answered May 25, 2016 by magma1447 (Admin) (218,480 points)
edited May 25, 2016 by magma1447 (Admin)
Thanks.  I'll throw together a GSAK macro that does the scrubbing. Fortunately the parenthesis you use is a pretty good identifier for a project-gc county name.  There are two exceptions I have found but those can be accounted for.