On Tue, Apr 17, 2012 at 16:16, David MENTRE <dmen...@linux-france.org> wrote: > Hello Étienne, > > 2012/4/17 Étienne Loks <etie...@peacefrogs.net>: >> On the other side, on the sample given by Jeroen there are problems with >> many "T" section probably because of streets begining with "'t". >> >> I take a look at this. > > I also saw this. But is it a MapOSMatic bug or an OSM bug? We should > not implement workarounds around OSM errors. :-)
Both and neither. It's an artifact of the language having been set to German. The index sort that I wrote for Dutch maps doesn't show this defect. It's due to a peculiarity of the Dutch language. Where French has Rue de la <x>, and you'd sort it as <x>, Rue de la, I do some similar magic with -L nl_NL.UTF8 that makes sense for Dutch articles/prefixes. The 't versus T case is a defect in ocitysmap that shows up in all languages other than Dutch, because they don't have the prefix work I've done. The streets are correctly named after all, so in the general i18n class the sort order could sort on a copy of the street name with spaces removed? There are plenty of defects in the data, though, which I'll fix once the OSM database is write-enabled again. By this I mean streets named twice like 'de Sering' vs. 'De Sering'. I'll upload the same area rendered with -L nl_NL.UTF8 so you can see what I mean. In short: Whilst there are defects in the OSM data that we shouldn't paper over, the 't / T case isn't one of them. That data is correct. Thanks, Jeroen. -- ↑↑↓↓←→←→BA[Start]
