Efter givande samtal md Sportmanship i går har jag förstått att problemet med de "text labels" jag och andra så innerligt önskar bort från Garminseriens toopokartor ligger redan i grundmaterialet.
Nuvarande grad av insikt: Källdata levereras från Lantmäteriet (och dess kollegor i NO, FI, BE, F, DE, UK, NL, CH) i form av vektordata från en nationell "grunddatabase". I denna databas finns referens till en objektsymbol för t ex hus och då även ett attribut i form av text "HUS" samt data för den aktuella positionen. Denna "text label" kallas jag ett statiskt attribut. Sedan finns även för linjer och ytor vad jag kallar dynamiska attribut vilket innebär att text kommer att visas om man för markören till linjen etc, t ex "vattendrag". Då man pekar på linjen kommer en referens att anropas och den aktuella texten visas. Det dynamiska attributets text är således inte bundet till en viss position utan till en viss typ av punkt eller linje. För övrigt dyker det dynamiska attributet också upp då man pekar på ett objekt som redan har ett statiskt attribut.
Det är de statiska attruibuten som är problemet. Texten "hus" ligger således inbäddad i datamängden knuten till varje position som anger en punkt med denna typ av objekt.
Enligt vad min sagesman på Sportmanship berättade igår är man väl medveten om problemet med överflödiga attribut och har försökt lösa dem i samarbete med Carmenta som stått för det tekniska arbetet med att ta fram den nya topokartan. Försöken att rensa datamängden från de "statiska" attributen har dock inte fallit väl ut.
Noteras kan, att de topokartor Garmin självt tagit fram (förmodligen tillsammans med ett specialiserat företag liknande Carmenta) inte innehåller statiska attribut. Se den nya brittiska topokartan:
http://www.garmin.com/cartography/mapSource/topogb.jsp
och den äldre kanadensiska ett steg upp i länken.
Det har framkastats i diskussion på ett internationellt forum att detta skulle bero på att i de på engelska skrivna programmen redan finns rutiner för att peka i en begreppsförteckning då markören förs till en viss typ av objekt. Enligt samtalet i går skulle så dock inte vara fallet, Garmin har de facto låtit rensa i källdata för de kartor man själv låtit ta fram. Begreppsförteckning på olika språk för e dynamiska attributen är ju redan implementerat i kartorna.
Varför statiska attribut utöver egennamn förs in i källdata är svårt att förstå. Här en suck från en nederländsk lantmätare och iQue-användare:
"About this eternal label pain in the neck: because all object types (such as house, street, city park) are implicitly known by their codes, putting labels such as "house", "street" and "city park" in the database for every occurrence of an object type is one of the purest forms of redundancy.
Labels should only be filled in the database if it is a proper name (e.g. a street name), and be left blank if the object has no proper name. But how do you know then what the type of a certain object without a proper name is? In this case a sort of object type dictionary is used. Imagine you tap on a certain object in the map. The database knows what the object type code is, and if the object has no proper name, the software looks in the object type dictionary for the object type description ("house" etc) coupled to this code.
Since the number of object types is not huge such a dictionary (or table) is not large. The point is, that this object type dictionary is in the English language only, and therefore (topo) maps of non-English language countries put the object descriptions in the labels.
If there would be some more effort in the further development of the object type dictionary, multilinguality could be introduced. Just say what language you want in Mapsource and the selected language will be used in that program, and copied to the iQue or any map using Garmin receiver.
All this seems simple. And it is, at least conceptually.
First, there should be a generic standard for Mapsource products regarding this multilingual object dictionary.
Second, third party Mapsource product makers should be enabled to add the object description in the language(s) of their choice to the dictionary. English should be available as a standard, so people who do not know the language(s) added by the third party, can select English instead.
Third, the Mapsource program should be altered to be able to cope with the multilingual object type dictionary, and probably the iQue (and other models) map software as well.
So, it is conceptually simple. And it reduces redundancy, leads to smaller databases, and the users are more satisfied with the product: no more superfluous labels, you can use the language of your choice, and third party products can reach non-native language markets better.
But the implementation?"
Nu tror jag allså inte att object labels/statiska attribut förs in först då garminkartorna tas fram på grundval av basmaterialet utan att de redan finns där i den ursprungliga datamängden. Och förmodligen kommer att fortsätta att finnas där.
Om rensning av databasen är alltför mödosam ur cost/benefitsynpunkt för de smala produkter som vektorbaserade topoprodukter ändå är så finns fortfarande möjligheten att utföra "post processing", dvs identifiera de statiska attributen i de enskilda kartfilerna och åtgärda dem där.
Enligt min sagesman har Sportmanship inga invändningar mot att användaren utför denna rensning - i föreliggande fall med Maptools (som egentligen heter MapModify). Man är medveten om de problem som finns och anser inte att lantmäteriets licensrättigheter påverkas av att vissa statiska attribut avlägsnas ur datamängden. Lantmäteriet gör för övrigt samma sak i sin egen hantering av grunddat för framställning av kartor.
Det vore naturligtvis önbskvärt att åtgärden kan ske på ett tidigare skede, innan försäljning. Här framfördes från annat håll ett antal synpunkter. Framför allt så ligger de statiska attributen längre ned i den nya Friluftskartan (högre grad av inzoomning krävs innan de dyker upp), vilket gör att de torde störa mindre. Dessutom är listan över tillgängliga kartsymboler begränsad faktiskt och dessutom möjligen av Garmin. Papperskartans symboler framgår här
http://www.lantmateriet.se/upload/filer/kartor/kartor/teckenforklaring/Terrangkartan.pdf
Och de för garminkartor tillgängliga i kartfilen FeaturesTest som kan laddas ned från
http://rwsmaps.griffel.se (Länk en tredjedel från slutet av sidan).
En snabb jämförelse visar att listorna inte överensstämmer. I terrängkartan utmärks ett hus och en höjdpunkt av olika symboler, i Friluftskartan av samma. Texten "HUS" gör att tvetydighet undviks (det kan man tycka att siffrorna vid höjdpunkt medger också. Min anm.) Eftersom ingen förteckning över innebörden eller innebörderna av symbolerna finns tillgänglig i Garminkartan - i papperskartan finns deni ramen, med symboler och förklaring på flera språk dessutom - behöver innebörden anges på plats. Tydligen räciker det inte med det dynamiska attribut som ändå finns tillgängligt genom att peka på objektet. Jag är för övrigt inte klar över om Garmin ytterligre inskränkt antalet symboler som får begagnas i förhållande till mängden i FeaturesTest.
Problemet berör ingalunda endast den svenska produktionen utan alla topokartor utanför det engelsspråkiga området. Något samlat initiativ från de nationella distributörern för att komma till rätta med det verkar inte föreligga och Garmin själva är ju endast indirekt berört.
Det vore därför angeläget att definiera problemet så adekvat som möjligt och föreslå åtgärder till de nationella distributörerna gemensamt. Jag vore därför i första ledet tacksam för synpunkter som kan leda fram till en fackmässig beskrivning av problemet, först på svenska och därpå på engelska. Sedan återstår att visa att Maptools kan användas och att komma fram till vad som vore önskvärt resultat.
[Ändrat av jonasolof 2006-01-20 kl 18:12]
Nuvarande grad av insikt: Källdata levereras från Lantmäteriet (och dess kollegor i NO, FI, BE, F, DE, UK, NL, CH) i form av vektordata från en nationell "grunddatabase". I denna databas finns referens till en objektsymbol för t ex hus och då även ett attribut i form av text "HUS" samt data för den aktuella positionen. Denna "text label" kallas jag ett statiskt attribut. Sedan finns även för linjer och ytor vad jag kallar dynamiska attribut vilket innebär att text kommer att visas om man för markören till linjen etc, t ex "vattendrag". Då man pekar på linjen kommer en referens att anropas och den aktuella texten visas. Det dynamiska attributets text är således inte bundet till en viss position utan till en viss typ av punkt eller linje. För övrigt dyker det dynamiska attributet också upp då man pekar på ett objekt som redan har ett statiskt attribut.
Det är de statiska attruibuten som är problemet. Texten "hus" ligger således inbäddad i datamängden knuten till varje position som anger en punkt med denna typ av objekt.
Enligt vad min sagesman på Sportmanship berättade igår är man väl medveten om problemet med överflödiga attribut och har försökt lösa dem i samarbete med Carmenta som stått för det tekniska arbetet med att ta fram den nya topokartan. Försöken att rensa datamängden från de "statiska" attributen har dock inte fallit väl ut.
Noteras kan, att de topokartor Garmin självt tagit fram (förmodligen tillsammans med ett specialiserat företag liknande Carmenta) inte innehåller statiska attribut. Se den nya brittiska topokartan:
http://www.garmin.com/cartography/mapSource/topogb.jsp
och den äldre kanadensiska ett steg upp i länken.
Det har framkastats i diskussion på ett internationellt forum att detta skulle bero på att i de på engelska skrivna programmen redan finns rutiner för att peka i en begreppsförteckning då markören förs till en viss typ av objekt. Enligt samtalet i går skulle så dock inte vara fallet, Garmin har de facto låtit rensa i källdata för de kartor man själv låtit ta fram. Begreppsförteckning på olika språk för e dynamiska attributen är ju redan implementerat i kartorna.
Varför statiska attribut utöver egennamn förs in i källdata är svårt att förstå. Här en suck från en nederländsk lantmätare och iQue-användare:
"About this eternal label pain in the neck: because all object types (such as house, street, city park) are implicitly known by their codes, putting labels such as "house", "street" and "city park" in the database for every occurrence of an object type is one of the purest forms of redundancy.
Labels should only be filled in the database if it is a proper name (e.g. a street name), and be left blank if the object has no proper name. But how do you know then what the type of a certain object without a proper name is? In this case a sort of object type dictionary is used. Imagine you tap on a certain object in the map. The database knows what the object type code is, and if the object has no proper name, the software looks in the object type dictionary for the object type description ("house" etc) coupled to this code.
Since the number of object types is not huge such a dictionary (or table) is not large. The point is, that this object type dictionary is in the English language only, and therefore (topo) maps of non-English language countries put the object descriptions in the labels.
If there would be some more effort in the further development of the object type dictionary, multilinguality could be introduced. Just say what language you want in Mapsource and the selected language will be used in that program, and copied to the iQue or any map using Garmin receiver.
All this seems simple. And it is, at least conceptually.
First, there should be a generic standard for Mapsource products regarding this multilingual object dictionary.
Second, third party Mapsource product makers should be enabled to add the object description in the language(s) of their choice to the dictionary. English should be available as a standard, so people who do not know the language(s) added by the third party, can select English instead.
Third, the Mapsource program should be altered to be able to cope with the multilingual object type dictionary, and probably the iQue (and other models) map software as well.
So, it is conceptually simple. And it reduces redundancy, leads to smaller databases, and the users are more satisfied with the product: no more superfluous labels, you can use the language of your choice, and third party products can reach non-native language markets better.
But the implementation?"
Nu tror jag allså inte att object labels/statiska attribut förs in först då garminkartorna tas fram på grundval av basmaterialet utan att de redan finns där i den ursprungliga datamängden. Och förmodligen kommer att fortsätta att finnas där.
Om rensning av databasen är alltför mödosam ur cost/benefitsynpunkt för de smala produkter som vektorbaserade topoprodukter ändå är så finns fortfarande möjligheten att utföra "post processing", dvs identifiera de statiska attributen i de enskilda kartfilerna och åtgärda dem där.
Enligt min sagesman har Sportmanship inga invändningar mot att användaren utför denna rensning - i föreliggande fall med Maptools (som egentligen heter MapModify). Man är medveten om de problem som finns och anser inte att lantmäteriets licensrättigheter påverkas av att vissa statiska attribut avlägsnas ur datamängden. Lantmäteriet gör för övrigt samma sak i sin egen hantering av grunddat för framställning av kartor.
Det vore naturligtvis önbskvärt att åtgärden kan ske på ett tidigare skede, innan försäljning. Här framfördes från annat håll ett antal synpunkter. Framför allt så ligger de statiska attributen längre ned i den nya Friluftskartan (högre grad av inzoomning krävs innan de dyker upp), vilket gör att de torde störa mindre. Dessutom är listan över tillgängliga kartsymboler begränsad faktiskt och dessutom möjligen av Garmin. Papperskartans symboler framgår här
http://www.lantmateriet.se/upload/filer/kartor/kartor/teckenforklaring/Terrangkartan.pdf
Och de för garminkartor tillgängliga i kartfilen FeaturesTest som kan laddas ned från
http://rwsmaps.griffel.se (Länk en tredjedel från slutet av sidan).
En snabb jämförelse visar att listorna inte överensstämmer. I terrängkartan utmärks ett hus och en höjdpunkt av olika symboler, i Friluftskartan av samma. Texten "HUS" gör att tvetydighet undviks (det kan man tycka att siffrorna vid höjdpunkt medger också. Min anm.) Eftersom ingen förteckning över innebörden eller innebörderna av symbolerna finns tillgänglig i Garminkartan - i papperskartan finns deni ramen, med symboler och förklaring på flera språk dessutom - behöver innebörden anges på plats. Tydligen räciker det inte med det dynamiska attribut som ändå finns tillgängligt genom att peka på objektet. Jag är för övrigt inte klar över om Garmin ytterligre inskränkt antalet symboler som får begagnas i förhållande till mängden i FeaturesTest.
Problemet berör ingalunda endast den svenska produktionen utan alla topokartor utanför det engelsspråkiga området. Något samlat initiativ från de nationella distributörern för att komma till rätta med det verkar inte föreligga och Garmin själva är ju endast indirekt berört.
Det vore därför angeläget att definiera problemet så adekvat som möjligt och föreslå åtgärder till de nationella distributörerna gemensamt. Jag vore därför i första ledet tacksam för synpunkter som kan leda fram till en fackmässig beskrivning av problemet, först på svenska och därpå på engelska. Sedan återstår att visa att Maptools kan användas och att komma fram till vad som vore önskvärt resultat.
[Ändrat av jonasolof 2006-01-20 kl 18:12]
.
