Re: [mkgmap-dev] TYP file. Descriptions and translations
Hi. Thank you! I will write it as Plac. (updates will occur in about a week) Regards Karl On måndag 26 oktober 2020 kl. 17:40:01 CET Andrzej Popowski wrote: > Hi Karl, > > > Square is probably "Rynek" in Polish but given the other mappings > > "Plac" should be as good. > > I guess "plac" is better word for a typ file, since it is a general term > describing a public area inside a city. "Rynek" has more precise meaning > in Polish, it is market square or the main square in an old town. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] TYP file. Descriptions and translations
Hi Karl, > Square is probably "Rynek" in Polish but given the other mappings "Plac" should be as good. I guess "plac" is better word for a typ file, since it is a general term describing a public area inside a city. "Rynek" has more precise meaning in Polish, it is market square or the main square in an old town. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] TYP file. Descriptions and translations
Hi Randolph
It's the actual editing of the file, looking at the context of the
typecode and then trying to come up with the best short string in ones
native or well understood language that takes the time, and then
getting agreement on the changes.
However, I have no problem with you adding (ie not overwriting) these
translations to mapnik.txt, but probably best to wait for Karl & Carlos
to finish their changes.
Regards
Ticker
On Sat, 2020-10-24 at 11:42 -0500, Randolph J. Herber wrote:
> Dear Sirs:
>
> Again I offer a set of translations via Google translate, which, of
> course, means that they need be edited by native language users.
> Nonetheless, I expect that they would be a useful basis from which to
> start.
>
> These languages already have been done (the codes before the arrows
> are
> the language codes that I had assigned arbitrarily):
>
> {"1d" -> "Albanian", "29" -> "Arabic", "09" -> "Basque",
> "2a" -> "Belarussian", "1e" -> "Bosnian", "23" -> "Brazilian",
> "22" -> "Bulgarian", "0a" -> "Catalan", "13" -> "Croatian",
> "12" -> "Czech", "0e" -> "Danish", "03" -> "Dutch",
> "04" -> "English", "06" -> "Finnish", "01" -> "French",
> "0d" -> "Gaelic", "0b" -> "Galician", "02" -> "German",
> "17" -> "Greek", "14" -> "Hungarian", "2e" -> "Irish",
> "05" -> "Italian", "25" -> "Japanese", "24" -> "Korean",
> "1a" -> "Latvian", "1b" -> "Latvian", "21" -> "Macedonian",
> "2c" -> "Moldavian", "2d" -> "Montenegrin", "0f" -> "Norwegian",
> "15" -> "Polish", "10" -> "Portuguese", "1c" -> "Romanian",
> "19" -> "Russian", "1f" -> "Serbian", "26" -> "Simplified Chinese",
> "11" -> "Slovak", "18" -> "Slovenian", "08" -> "Spanish",
> "07" -> "Swedish", "28" -> "Thai", "27" -> "Traditional Chinese",
> "16" -> "Turkish", "2b" -> "Ukrainian", "0c" -> "Welsh"}
>
> For example, I already know that the Portuguese translation is a
> mixture
> of dialects, including Brazilian and Iberian peninsula.
>
> Sincerely,
>
> Randolph J. Herber
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Commit r4588: fix link to TYPViewer (TYPViewsite.patch by Ticker Berkin)
Version mkgmap-r4588 was committed by gerd on Mon, 26 Oct 2020 fix link to TYPViewer (TYPViewsite.patch by Ticker Berkin) http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap=4588 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] TYP file compiler manual
Hi Gerd Patch attached to fix this Ticker On Sat, 2020-10-24 at 11:03 +0100, Roger Calvert wrote: > Have found that the link to TYPViewer in the TYP file compiler manual > is > broken. The new link for this resource seems to be > https://sites.google.com/site/sherco40/ > > Regards, > > Roger > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-devIndex: doc/typ-compiler.txt === --- doc/typ-compiler.txt (revision 4587) +++ doc/typ-compiler.txt (working copy) @@ -19,7 +19,7 @@ set/encoding. Also they make assumptions about the chars used to represent colours in icons and might change them. -These produce file formats that differ from each other and have variations to the specification that is presented here. These variations will be supported as they are discovered as long as they do not conflict with each other, but are not listed here for clarity. In particular the files produced by [http://www.pinns.co.uk/osm/ostyp.html TYPWiz] and [http://opheliat.free.fr/michel40/ TYPViewer] are supported. +These produce file formats that differ from each other and have variations to the specification that is presented here. These variations will be supported as they are discovered as long as they do not conflict with each other, but are not listed here for clarity. In particular the files produced by [http://www.pinns.co.uk/osm/ostyp.html TYPWiz] and [https://sites.google.com/site/sherco40/ TYPViewer] are supported. == The [_id] section == ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] TYP file. Descriptions and translations
Hi Karl See embedded Regards Ticker On Fri, 2020-10-23 at 18:36 +0200, 7770 wrote: > Hi. > I am working my way through adding swedish translations to as many > types as > possible in the mapnik.txt file. > Currently i am done with the polygons. > > Aside from adding swedish i observe a few things which may be > incorrect named. > Numbered but in no particular order. > The attached file does also contains a few in polish translations, > those are > mentioned here, and also included in the file. > > > 1. > The style: leisure=water_park [0x09 resolution 21] > has the TYP: > [_polygon] > type=0x09 > ;GRMN_TYPE: Large Manmade Areas/MARINA/Marina area/Non NT > String=Marina > String1=0x01,Piscine > String2=0x02,Schwimmbad > String3=0x04,Water Park > String4=0x03,Zwembad > String7=0x15,Basen > String8=0x10,Piscina > String9=0x05,Piscina > ... > > For me a marina is very different from a water park. > In this case i tend to say that the mapping in the style polygons > file is > questionable. > Perhaps it should be: leisure=marina [0x09 resolution 21], or both > marina and > water_park. > > As for the names in the TYP file, the english name indicates marina, > but all > others indicate Swimming pools, bath. > Some of the codes used in the default style are not ideal. I think the Garmin polygon code 0x09, which, without a TYP file, shows as "Marina" on Garmin software that chooses to show such things, should be used to represent a marina - OSM tag leisure=marina. If this is done, then other codes need to be used for leisure=water_park and leisure=swimming_pool | amenity=swimming_pool There are a lot of polygon codes that represent various forms of water (0x28 .. 0x49) and many of these are unused by the default style. I use 0x2a for water_park and 0x3e for swimming pool. > > > 2. > Possible incorrect translations. > [_polygon] > type=0x12 > ;GRMN_TYPE: // > String=Retail > String1=0x01,Aire > String2=0x02,Raststätte > String4=0x03,Snelweg rustplaats > ExtendedLabels=Y > FontStyle=NoLabel (invisible) > CustomColor=No > Xpm="0 0 1 0" > "1 c #EFC8C8" > [end] > > I think it is because two rules in the styles map to this type. > highway=services [0x12 resolution 22] # service station complex;.. > landuse=retail [0x12 resolution 20-23] > > It looks like the English speaker has thought of a retail area > (landuse=retail) whereas the others thought more of highway=services > > Compare with: > https://wiki.openstreetmap.org/wiki/Map_Features Landuse section. > > I cant give a good idea what would be the best way to resolve this, > perhaps > map differently? > I don't see a problem with using the same code for landuse=retail and highway=services; a service area has a mix of shops (including fuel sales), parking etc, much like a retail area. However, as you note, the translations are not consistent - they should be Retail, rather than Rest Stop. > > > 3. > All strings have String1 (should work, just bad looking). > > [_polygon] > type=0x25 > ;GRMN_TYPE: // > ;See also 0x6b for pedestrian area > String=Square > String1=0x01,Place > String1=0x02,Platz > String1=0x03,Markt > String1=0x05,Piazza > String1=0x08,Plaza > ExtendedLabels=Y > FontStyle=NoLabel (invisible) > CustomColor=No > Xpm="0 0 1 0" > "1 c #E8" > [end] > Not really a problem > > > 4. > Polish translation updated (0x15). > > [_polygon] > type=0x46 > ;GRMN_TYPE: Water Areas/LARGE_RIVER/Major river, typically at least > 700 ft in > width/Non NT > String=River > String1=0x01,Eau > String2=0x02,Wasser > String4=0x03,Water > String7=0x15,Rzeka > String8=0x10,Água > String9=0x05,Acqua > ExtendedLabels=Y > FontStyle=NoLabel (invisible) > CustomColor=No > Xpm="0 0 1 0" > "1 c #AAD3DF" > [end] > Good - hope the other languages gradually get improved to say River > > > 5. > Polish translation updated.(0x15). > > [_polygon] > type=0x47 > ;GRMN_TYPE: Water Areas/RIVER_GT_700FT/Major river greater or equal > to 700 ft > in width/Non NT > String=Waterfall > String1=0x01,Eau > String2=0x02,Wasser > String4=0x03,Water > String7=0x15,Wodospad > String8=0x10,Água > String9=0x05,Acqua > ExtendedLabels=Y > FontStyle=SmallFont > CustomColor=Day > DaycustomColor:#4D80B3 > Xpm="0 0 1 0" > "1 c #AAD3DF" > [end] > and waterfall > > 6. > Polish translation updated (0x15). > > [_polygon] > type=0x48 > ;GRMN_TYPE: Water Areas/RIVER_100FT, SMALL_RIVER/Minor river, > typically less > than 700 ft in width/Non NT > String=Canal > String1=0x01,Eau > String2=0x02,Wasser > String4=0x03,Water > String7=0x15,Kanał > String8=0x10,Água > String9=0x05,Acqua > ExtendedLabels=Y > FontStyle=SmallFont > CustomColor=Day > DaycustomColor:#4D80B3 > Xpm="0 0 1 0" > "1 c #AAD3DF" > [end] > and canal > 7. > Polish translation updated (0x15) > [_polygon] > type=0x4b > ;GRMN_TYPE: Map Bounds/DATA_BOUNDS/Bounds of map after creation/Non > NT > String=Area of Map Coverage > String1=0x01,Sol > String2=0x02,Hintergrund > String4=0x03,Achtergrond > String7=0x15,Tle
