Summitslist.csv invalid entries

Hi,
starting from 04/12/2014 I’m seeing these two invalid entries in the exported file:

CU/CU-FA-002,Azores,Faial,Cabeço Verde,487,1598,-28.79694,38.5919,-28.7969,38.5919,1,0,01/12/2014,31/12/2099,0,,,
CU/CU-PI-002,Azores,Pico,Cabeco do Escalvado,1077,3533,-28.213954,38.440554,-28.2140,38.4406,8,0,01/12/2014,31/12/2099,0,,,

It looks like the Association code is duplicated.
The same summit codes appear on http://www.sotadata.org.uk/

Thanks,
IZ1KSW - Gab

Yep. There is a hyphen instead of a slash in the base data - now fixed. That just needs to work through.
Jim

Gab, thanks for the eagle-eye observations. Database is updated now. A new summitslist.csv will be available tomorrow morining. SOTAwatch will follow.

Hi Jim and Andy,
I confirm that this morning’s export looks good.
Thanks for fixing that so quickly.

IZ1KSW - Gab

Whilst working on my SOTA CSV Editor I noticed that the following Summits in the XLS have HTML codes embedded in the names:

W0C/RG-154
W0C/RG-161
W0C/RP-029
W7I/NP-141
W7N/ES-046
W7N/WP-042
W7W/WH-111
W7Y/EW-092
W7Y/PA-180

Stewart G0LGS

Thanks for the headsup Stewart. This is a hangover from when the DB was extended to support Unicode characters. Everything uploaded since the switchover will be correct even if it uses non-Roman characters. Anything uploaded before that used non-Roman characters may be fine still. But it may have been converted to a best fit before and now gets mishmashed when the CSV is generated.

One of your hills listed shows as “South Piñon Hills HP”. However, instead of the codepoint for ‘ñ’ being in the name, ‘&ntilde’ is inserted.

Slowly these will get sorted as we reload data.