Watertown, South Dakota can't be the default location

Bug #568289 reported by Burt P.
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Stellarium
Fix Released
Medium
Bogdan Marinov

Bug Description

Typing Watertown into the search box returns a list of Watertowns with their states in parenthesis, all except the last one which is just "Watertown, United States". This is Watertown, South Dakota. When the location is selected, the Name/City box says "Watertown (South Dakota)". The default location is saved in config.ini as "Watertown (South Dakota), United States", but when Stellarium is restarted, the error
Warning: location "Watertown (South Dakota), United States" is unknown
is dumped into the terminal, and Paris is used as the location again. If config.ini is manually edited to use "Watertown, United States" as the default location, it will start in Watertown instead of Paris.

Revision history for this message
Bogdan Marinov (daggerstab) wrote :

I can confirm this. Something is wrong with the way in which locations that belong to a subdivision are handled.

For example, in my build, some of the other Watertowns are displayed as "Watertown (New York) (New York)" both in the list and in the "Name" field. Side effect from the transition to binary format?

Changed in stellarium:
importance: Undecided → Medium
status: New → Confirmed
Revision history for this message
Matthew Gates (matthew-porpoisehead) wrote :

I see the double (New York) (New York) as well. However, I changed the loadCitiesBin for loadCities("base_locations.txt", false), and still see the same effect - the "South Dakota" is missing in the list, and it doesn't save the location at all (reverts to Paris).

I can't see anything weird about the file. Correct delimiting, nothing invalid looking about any of the fields. I also checked lines above and below each of the Watertown records (yay for grep -C 1), and nothing looks wrong with the file. Curious!

Changed in stellarium:
assignee: nobody → Bogdan Marinov (daggerstab)
Revision history for this message
Bogdan Marinov (daggerstab) wrote :

A fix has been committed to Stellarium's code repository at SourceForge as revision 6254:
http://stellarium.svn.sourceforge.net/viewvc/stellarium?view=rev&revision=6254

This was caused by the mechanism for avoiding duplicate location names. I've fixed it, but I don't like the way it works.

At the moment, it favours the last added location. For example, if there are five towns, each with a different state specified, four will end up in the list as "Town X (State Y), USA", and the last one will be only "Town X, USA". Shouldn't the state/province modifier be applied to all locations that have it?

Changed in stellarium:
milestone: none → 0.10.5
status: Confirmed → Fix Committed
Revision history for this message
Matthew Gates (matthew-porpoisehead) wrote :

The commit includes a change for base_locations.bin.gz but not base_locations.txt. Shouldn't there also be an update for base_locations.txt?

Revision history for this message
Bogdan Marinov (daggerstab) wrote :

No. The binary file is not a direct binary version of the text file. Instead, the binary file is created by loading the text file to a data structure and then serializing the data structure to a file. The bug was in the method that loaded the names from the text file, so the mishandled names ended up in the binary file.

Also, the binary file need to be gz-ed manually, which almost made me think that I haven't fixed the bug on the first test run - Stellarium used the old .gz file instead of the freshly generated .bin file.

Changed in stellarium:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.