Re: [mkgmap-dev] documentation of new option in branch

On 2019-11-05 11:12, Ticker Berkin wrote: > Also fix "metres" to "meters" Metres is the correct UK spelling, nothing to fix here___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Turn restrictions - via ways

was added with the merge of > the via_ways branch in r3175. > http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap=3175 > > Gerd > > > Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Colin > Smale <

[mkgmap-dev] Turn restrictions - via ways

Hi, I just read that the iD editor now includes support for via ways in turn restrictions. Making them so accessible means that in time we are going to see more and more of these constructions. If I am not mistaken mkgmap can only handle a via point as a node in a turn restriction, because

Re: [mkgmap-dev] Strange long distance routes on Nüvi

What needs to be embedded into the map, is the Location Table which maps the location IDs in the TMC messages to roads, junctions etc in the map network. The radio messages only contain location IDs, not lat/lon. Not all location tables are available as open data - each country has its own

Re: [mkgmap-dev] Is height: filter working as described?

I am not sure how far mkgmap should exceed its original scope and become a QA tool... But maybe an option to configure the output format of the height and conv functions (w.r.t. decimal separator, thousands separator, number of digits etc) might be useful? Perhaps the program could take (some of)

Re: [mkgmap-dev] Commit r3696: Fix documentation error.

More brackets than you can shake a stick at... https://en.wikipedia.org/wiki/Bracket On 2016-10-17 05:14, Dave Swarthout wrote: > So, are these changes included in the new style manual that comes in the > mkgmap installation package? > > Also, a small note about terminology. This issue pops

Re: [mkgmap-dev] How do I transform the name of all Ways?

Hi Alexandre, I use an Excel spreadsheet (enclosed) to do this kind of transformation for Dutch-language street names. There's a macro (Alt-f11) which writes a file "fix_names" (the path is hard-coded in the macro code, sorry about that - please edit to suit). There's a tab for prefixes, one for

Re: [mkgmap-dev] Has anyone added a USA TIMEZONE overlay ontop of their custom maps?

According to wikipedia, timezone boundaries seems to be a rather complex subject in the USA, with some communities using an unofficial time as well as many variations of the application of Daylight Savings time... Indiana specifically is described in some detail on wikipedia [1]. I agree with

Re: [mkgmap-dev] Minimum size for a "_link" to process "destination"

If I recall correctly, Garmins don't use the road name for links. Instead they use the name of the first non-link road, i.e. where the link leads to. So the first bit of the exit ramp stays as a link (road type 0x08 or 0x09), and a short bit in the middle gets the destination as a name, so the GPS

Re: [mkgmap-dev] sorting the values?

Just to add to the complexity, I notice that the values in the ways you reference use a comma as decimal separator, not a dot as per OSM standard. So even if you split the values, you may still not get the result you expect. Is there a lot of this? Does mkgmap handle 2.5 and 2,5 the same in a

Re: [mkgmap-dev] motorvehicle=delivery seems to be ignored ?

>From an English-speaking standpoint I would associate delivery (in the context of "no entry except for delivery" for example) with the purpose of your visit (i.e. to deliver something) but not specific to a particular sort of vehicle, and not in itself related to the possession of individual

Re: [mkgmap-dev] Trying to get EXIT info on my MONTANA 600 using mkgmap -3657 and motorway_junction, ref=(exit#)

Could the lists of tags maybe be externalised into the config file, with a sensible default? //colin On 2016-01-21 14:37, A. Carlos wrote: > Thank you Gerd > > I will try to do it here, but if you can change there and release a beta > version. > Here we have many cases that this rule can be

Re: [mkgmap-dev] Subject: Time Zones in the USA defined or not?

They might not be painted on the ground, but they are verifiable, by reference to admin boundaries and the appropriate laws. On 2016-01-21 17:57, EthnicFood IsGreat wrote: >> Date: Wed, 20 Jan 2016 17:09:27 -0500 >> From: greg crago >> To: Development list for mkgmap

Re: [mkgmap-dev] Address search index questions.

I attempt to handle this kind of thing in the styles, for addresses in the Netherlands where the most significant part is usually the last word of the street name and the first few words may be "filler" information - often personal names/titles etc of famous people. Using the following rules I

Re: [mkgmap-dev] Slash character in name

I have noticed that the slash, plus all following text, is mostly suppressed on my Nuvi 2795. The official Garmin maps manage to use a slash between multiple refs and destinations - maybe they are escaping it in some way? Looking at the same file with BaseCamp shows that the full text is present

Re: [mkgmap-dev] Should we exclued bridges from housenumber processing?

Are there not going to be some complaints from Florence for example? Why should it be invalid by definition to have an address on a bridge? Sometimes the bridges are tagged (often wrongly, IMHO) with the name of the bridge and not the name of the road carried by the bridge. Some people use

Re: [mkgmap-dev] Duplicate cities

Thanks Gerd On 2015-05-22 09:34, Gerd Petermann wrote: Hi Colin, it turned out that your concerns were okay, the differences in the UK are much higher, so I've implemented a new option wanted-admin-level. See also post for splitter 423. Gerd - From:

Re: [mkgmap-dev] Duplicate cities

Could the admin_levels be made configurable in some way? There are considerable differences in the size of these areas between different countries. I am thinking particularly of the lower admin_level (5) which might be better set to 6 (or even 8) in the UK. Level 5 corresponds to regions which

Re: [mkgmap-dev] Duplicate cities

Well, I am thinking that the whole of the boundary of Scotland for example (level 5 is the region, level 4 is the nation - they are coterminous) will add an enormous overhead to all the tiles in Scotland. Maybe it isn't worth it, especially if you say it is complex to implement. As an aside,

Re: [mkgmap-dev] open issues in the housenumber2 branch

Gerd, Thanks for the explanation, and sorry if I missed it before. So we have two extremes: on the one hand accuracy which would best be served by having individual addresses in the output; on the other hand we have efficiency (storage and lookup performance?) which would call for

Re: [mkgmap-dev] open issues in the housenumber2 branch

Gerd, can you explain how addresses are stored in the Garmin maps? Are they millions of individual nodes, or interpolation ways with a start and an end? Are they just coordinates, or are they internally linked to a road in some way? Can it handle non-numeric house numbers? Understanding the

Re: [mkgmap-dev] mixed index branch merge

The stopword processing should be language-specific and not (solely) based on admin boundaries... One man's stopword is another man's significant proper name. I agree that the languages which prefix the road type (like French and Spanish) are most in need of this, but it is a little less

Re: [mkgmap-dev] mixed index branch merge

What about multi-lingual countries such as Belgium or Switzerland? I think the primary factor should be language, not country. Belgian French, French French and Swiss French are probably similar enough for these purposes that they can share a solution. But Belgian French and Belgian Dutch are

Re: [mkgmap-dev] mixed index branch merge

On 2015-02-14 20:45, Marko Mäkelä wrote: On Sat, Feb 14, 2015 at 03:57:21PM +0100, Colin Smale wrote: What about multi-lingual countries such as Belgium or Switzerland? Or multi-lingual cities, such as Montréal in Canada? But, is this really an issue? Street signs may be in two or more

Re: [mkgmap-dev] multi-word street search

Andrzej, I couldn't find the description of the problem this aims to fix but if I am guessing right it will add individual words from street names into the index so they can be found when searching for an address? Will this not add millions of entries for The and Road and similar articles,

Re: [mkgmap-dev] [Patch v3] drive-on-left/drive-on-right handling

I can't see how that would work, unless you can deduce that two parallel one-ways are part of the same dual carriageway. And that's an algorithm that many people would like to have, I'm sure... Colin On 2014-12-02 13:45, GerdP wrote: Hi Andrzej, do you think that we should count all

Re: [mkgmap-dev] [Patch v1] style filter country-ISO

Hi Gerd, Is there a typo in the change to the rules? It looks like there's an extra dash in one of them. +mkgmap:country!=* addr:country=* { set mkgmap:country='${addr:country|country-ISO:}' } +mkgmap:country!=* is_in:country=* { set mkgmap:country='${is_in:country|country--ISO:}' }

Re: [mkgmap-dev] Non-rectangular tiles

On 2014-11-27 07:27, Thorsten Kukuk wrote: On Thu, Nov 27, Steve Ratcliffe wrote: I was meaning to write a message about this for a while and since the thread for drive-on-left/right has brought this up already today and since it is a mkgmap birthday (8 years!) this might be a good

Re: [mkgmap-dev] Manage drive-on-left/drive-on-right in resources\LocatorConfig.xml

and Hong Kong? Colin On 2014-11-26 18:26, GerdP wrote: Hi Colin, Colin Smale wrote How can we make the behaviour deterministic where the map area covers both? For example, you can't make a rectangular box around the UK without including bits of France. If the splitter/mkgmap combo

Re: [mkgmap-dev] Manage drive-on-left/drive-on-right in resources\LocatorConfig.xml

How can we make the behaviour deterministic where the map area covers both? For example, you can't make a rectangular box around the UK without including bits of France. If the splitter/mkgmap combo decides to start in the bottom right, the whole of the UK will be driving on the right. So I

Re: [mkgmap-dev] Incorrect runabout exit indication

Is it possible that your Garmin only has icons for 3-6-9-12 o'clock and is rounding off the angle in a funny way? It may be a fraction over 180 degrees and so getting rounded up (wrongly) to what you see. I have looked at the OSM data for that roundabout and there is nothing wierd there as far

[mkgmap-dev] Address nodes and Style Processing

Hi! Is it possible that pure address nodes (i.e. not POIs with address information) somehow don't go through the style processing with the points file? I have been adding a few debug statements and things are not working as I expected... Regards, Colin

Re: [mkgmap-dev] [PATCH v1] Fix handling of housenumbers for street names changed by style

Hi Gerd, WanMil, Did this patch make it into the base product? Colin On 2014-06-03 13:34, GerdP wrote: Hi Colin, see http://files.mkgmap.org.uk/download/214/mkgmap.jar [1] Gerd Colin Smale wrote This is excellent news! Now I will be able to manipulate abbreviations

Re: [mkgmap-dev] [PATCH v1] Fix handling of housenumbers for street names changed by style

This is excellent news! Now I will be able to manipulate abbreviations and suffixes in street names. At the moment I don't have the setup to build the program myself... Could someone provide a jar-file so I can give it a test? Thanks again, Colin On 2014-06-01 13:26, WanMil wrote: Hi

Re: [mkgmap-dev] Bug in subst

Hi Steve, I just tested it and it seems to be working fine. Thanks very much indeed for the quick service! Best regards, Colin On 2014-05-28 23:14, Steve Ratcliffe wrote: Hi name=* highway=* {set name='${name|subst:^(Doctor|Dokter) ~Dr }'} The attached patch makes this

Re: [mkgmap-dev] Bug in subst

Hi Steve, I just tested it and it seems to be working fine. Thanks very much indeed for the quick service! Best regards, Colin On 2014-05-28 23:14, Steve Ratcliffe wrote: Hi name=* highway=* {set name='${name|subst:^(Doctor|Dokter) ~Dr }'} The attached patch makes this possible, and

[mkgmap-dev] Bug in subst

Hi, Is this the best way to make bug reports? I couldn't find a 'trac' for mkgmap... Using r3230, if I have the following in a style file: name=* highway=* {set name='${name|subst:^(Doctor|Dokter) ~Dr }'} then mkgmap crashes while loading the style files. After doing various tests my

Re: [mkgmap-dev] House numbers and styles

Hi Wanmil, Gerd, That would be wonderful. If you need any more information from me, feel free to get in touch! Colin On 2014-05-26 20:10, WanMil wrote: Hi Gerd, maybe I find some time on the weekend to have a look on it. WanMil Hi Colin, I think you found a bug in the

[mkgmap-dev] subst function and literal dots in regular expressions

Hi, I am trying to normalise street names by removing any dots. So far I have been unable to get the subst function to do what I want. The problem seems to be getting the dot to be taken literally in the subst parameters. I have tried: a) set newname='${name|subst:. += }' b) set

Re: [mkgmap-dev] subst function and literal dots in regular expressions

wanted to avoid double spaces, but now I know that is taken care of later, things are a simpler. Colin On 2014-05-25 12:49, Steve Ratcliffe wrote: On 25/05/14 11:14, Colin Smale wrote: I am trying to normalise street names by removing any dots. So far I have been unable to get the subst

[mkgmap-dev] House numbers and styles

I have some rules which modify name, addr:street and mkgmap:street in lines and points which apply some transformations to the street names. The idea is to normalise the names by removing punctuation and standardising abbreviations. The resulting map is missing the house numbers for streets

Re: [mkgmap-dev] Commit: r3259: remove most checks regarding routable/non-routable types.

Hi Gerd, I certainly was not envisioning anything with SQL! More like an ini-file. At present the program itself and the default styles have to address all kinds of devices, so they probably play it safe. Users can customise the program and styles or develop their own, but there is no

Re: [mkgmap-dev] Commit: r3259: remove most checks regarding routable/non-routable types.

Andrzej, you are absolutely right. The problem you describe is exactly what I was addressing earlier. I am hoping to allow a user of mkgmap to allow for these differences in behaviour by using a simple text editor, instead of a Java IDE. I propose making this accessible to the masses instead of

Re: [mkgmap-dev] Commit: r3259: remove most checks regarding routable/non-routable types.

As there are clearly differences in features supported by various models, would it maybe be an idea to externalise the differences in some way? How about a file to contain the capabilities of device types, an option to target a particular entry in that file, and a way to expose the selected

Re: [mkgmap-dev] [PATCH v3] Rework of inc/access

Another couple of examples of country defaults for NLD: cycleway: add mofa=yes; add moped=no motorway/link: add bicycle=no; add mofa=no; add moped=no; add foot=no; add agricultural=no; add maxspeed=130; Would it be more manageable to have a directory structure containing a small file per

Re: [mkgmap-dev] [PATCH v3] Rework of inc/access

It would make it easier for someone (a moped rider?) who wanted to make a special-purpose map for routing on his moped. The point I would like to make, is that once you have a central place for country specific rules (some may say country defaults but that may be a dangerous term to use in the

Re: [mkgmap-dev] Infinite loop splitter

R320 certainly seems to have fixed it for me. If there is still a problem with osmconvert etc then the new splitter appears to cope with it somehow. I will keep an eye on the maps coming out of mkgmap in case there any anomalies, but so far it's looking good. Thanks for the fix! Colin On

Re: [mkgmap-dev] Infinite loop splitter

I see this very often as well, when I use osmupdate on an earlier download. The only solution I have found is to download a new pbf, then it works again. I suspect therefore that osmupdate or one of the underlying tools is corrupting the data. Colin On 8 March 2014 10:44:16 CET, Minko

Re: [mkgmap-dev] Final call for merging the mergeroads branch

Can you please phrase it so that people not so familiar with the terminology are not confused or put on the wrong track? As a start, I would suggest trying to word it without the use of quotation marks, which instantly imply that you need to understand what those words (not persistent) mean in

Re: [mkgmap-dev] r2829 in the high-prec-coord branch

Just a thought... could this also explain why I sometimes get told to keep left at an exit on a straight motorway, which is a redundant way of saying do not take the exit? I haven't been able to discover any logic related to the tagging or the geometry in the OSM data. Colin On 2013-11-18

Re: [mkgmap-dev] r2829 in the high-prec-coord branch

Hi Gerd, I have been noticing this for a long time. I am not using adjust-turn-headings. I tried it some time ago and decided at that time that it was not an improvement. I haven't tried high-prec-coord yet although it is sounding like it might be pretty stable now so I might give it a go!

[mkgmap-dev] Phone number normalisation with style functions

Hi, Following a discussion on talk-gb about ways of formatting a phone number I decided to see how far I could get with the current style functions in mkgmap. I was very pleasantly surprised! The recent additions of subst with a regex and the part function have allowed me to get an almost

Re: [mkgmap-dev] Drive-on-left

Thanks for this WanMil! Although the original patch appeared to work at first, it turned out to work in some areas and not in others. I was trying to find some kind of logic in what worked and what didn't, but I think you hit the nail on the head. I just tried it out with the v2671 jar and it's

Re: [mkgmap-dev] Drive-on-left

Hi Steve and list, Thanks very much for committing that change! On 2013-08-13 10:50, Steve Ratcliffe wrote: Hi live with that very easily, but I wonder if the final value of that implication could be propagated to the TRE header somehow, so it is simpler to document and understand?

Re: [mkgmap-dev] Drive-on-left

) which ImgTool also reveals. Colin On 2013-08-06 23:46, Steve Ratcliffe wrote: On 06/08/13 21:01, Colin Smale wrote: Hi Steve, thanks for the patch... any chance of a jar file please? Then I can check it out. Will this find its way into the standard code? Sure, here you go: http

Re: [mkgmap-dev] Search addresses for latin countries (help on reg exp)

On 2013-08-06 09:51, Thorsten Kukuk wrote: With mkgmap:country we should be able to decide on 2, which list of words should be ignored for this country in the index. Would it not also need to be dependent on a language selection for multilingual countries such as Belgium? The treatment of

Re: [mkgmap-dev] Drive-on-left

wrote: On 05/08/13 19:30, Colin Smale wrote: I took a look at the code and saw that the drive-on-left and drive-on-right flags are only used to set a flag in NODHeader.java. However I just discovered ImgTool[1] which exposes the TRE parameters, a sequence of four numbers which, I

[mkgmap-dev] Drive-on-left

Hi, In the last couple of years I have been making maps with mkgmap for both the UK and various continental countries. One problem that I have never been able to fix until now is that the drive-on-left flag didn't seem to have any effect on roundabouts in the UK. The impact is limited because

Re: [mkgmap-dev] Adaptions in style (needed to make good use of) for overview2 branch

place=capital can surely never be right. The place is not a capital INSTEAD of being a village/town/city etc. The capital bit is the status of the place within an administrative entity and the place. The place can have a different capital status in different admin areas at the same time. Being

Re: [mkgmap-dev] New filter function trim

Great idea indeed! It would be wonderful if it could be complemented by a function to return the rest of the tag value (i.e. the values 2-n) such that these functions could be called repeatedly to get at the second, third etc values. Then we can really do some clever things. In my mind I can

Re: [mkgmap-dev] Weekend in Essen

They sound like great ideas! - Split maps along country borders. This would allow maps to be fully customised to country conventions. I'd always thought of this being a splitter function and it would be ideal to perform it there, but it could perhaps be done using the multi-polygon code.

Re: [mkgmap-dev] Remove createbounds option?

On 2012-12-20 21:43, WanMil wrote: In the discussion about cleaning the options list there was the idea to remove the createdbounds option and put that to a separate program. The program already exists so it's easy to realize that. Which program is this? All the information I can find

Re: [mkgmap-dev] address index question

i agree that the usage of pre-compiled bounds could be clearer, especially to outsiders who don't/can't read whole threads in the archives and distill their conclusions from there... How do I use mkgmap to make a perfectly up-to-date map, including a similarly up-to-date index? One obvious way

Re: [mkgmap-dev] [proposal] Display the destination

Hi, I am also doing this. In addition, there is an undocumented tag dest_ref (sometimes destination_ref) used to contain the ref of the road that the exit leads to. I override the ref of the ramp with dest_ref as the ref of the ramp is usually either the exit number or the ref of the motorway

Re: [mkgmap-dev] benefit of --drive-on-left

There is one cosmetic difference I have noticed. The roundabout junction diagram in the top left of the Garmin screen always reflects the drive-on-left/drive-on-right mode. If I compile a map for the UK without drive-on-left, the spoken and written routing instructions are correct (so turning

Re: [mkgmap-dev] Issue when routing across two countries

I see this as well. I create separate maps from separate downloads for Netherlands, Belgium, Nord-Pas de Calais, UK. Then I merge them into a single gmapsupp.img by referencing the tile img files: java $(LOGOPTS) -Xmx1400m -jar $(MKGMAP_W) --read-config=$(CFG_MERGE_W) $(WORK_BNL_W)\\6*.img

Re: [mkgmap-dev] How to create a map covering Fiji Samoa?

Gerd, I have no idea how to answer your question, but I was wondering if it is really connected to the IDL or the 180-degree longitude? Of course 179.99 East is separated from 179.99 West by only 0.02 degrees, not 359.98. I can imagine how this would need some special handling. The IDL

Re: [mkgmap-dev] TYP compiler

Hi I'd like to merge the typ branch back soon, since the changes that affect mkgmap have been done and are small. I've written a page describing the syntax of the language accepted by the compiler to accompany it: http://wiki.openstreetmap.org/wiki/Mkgmap/help/typ_compile Are the

Re: [mkgmap-dev] Commit: r2092: Translate motor_vehicle and vehicle access rules.

Marko, I see that the default style now effectively translates motor_vehicle to motorcar. Looking at the wiki and according to my understanding, motor_vehicle is a hypernym covering motorcar, hgv, psv etc etc. So now motor_vehicle=no will prohibit cars, but allow buses and trucks? Not sure if

[mkgmap-dev] Support for motor_vehicle=*

for the purposes of this sign. If these subtleties are different in other countries, it can easily be adapted by referencing mkgmap:country. Is this a reasonable way to do this? If so, could it be added to the standard mkgmap distribution? Best regards, Colin Smale

Re: [mkgmap-dev] Support for motor_vehicle=*

On 10/10/2011 21:36, Felix Hartmann wrote: On 10.10.2011 20:23, Colin Smale wrote: Having retagged some roads in my area as a result of some changes to road layouts, I noticed that my Garmin was routing me over a bit of road which I had tagged motor_vehicle=no. The road is signposted

[mkgmap-dev] Self-compiled r2008 doesn't work with PBF input

= Label.squashSpaces(element.getTag(int_ref)); if(int_ref != null) { +// Colin Smale, July 2011 +// remove space from European route number to stop it being read as 'East' +int_ref = int_ref.replaceAll(E *,E); if(ref == null

Re: [mkgmap-dev] Using exit refs in routing directions

On 14/07/2011 11:05, Charlie Ferrero wrote: Hello list, Is there any way to get mkgmap to embed exit refs (where they exist) in the routing directions, so that instead of getting: Exit right onto ramp you get Take exit 32 right onto ramp or something similar? Is this something that

Re: [mkgmap-dev] Routing restriction points

On 07/06/2011 13:28, ValentinAK wrote: Hi! How to make a restriction of access on the road if it contains a point with barrier=bollard or barrier=gate? I mean are the same as the turn restrictions with relations type=restriction. In my experience these barrier nodes are effectively ignored,

Re: [mkgmap-dev] [locator] Country specific rules

Possibly not what you have in mind, but how about an automatic drive-on-left for UK/Ireland/Japan/Australia/NZ/etc? On 04/05/2011 19:02, WanMil wrote: I want to start to collect and commit your country specific rules. I know some of you have already posted them on the list but I have lost

Re: [mkgmap-dev] Address search and index.

4) There are such things as cities that span multiple counties (like London, England for instance). There needs to be rules to allow that, maybe where the bounding-box for the majority of the county of Middlesex is required to be entirely outside the bounding box for London, but a second