Re: [mkgmap-dev] Problems with routing on Etrek 20 with latest firmware

[Bill]

Try running a zip program on the non gcd file.  (I normally use 7z, but 
I assume other will work as well)

It should let you extract the GUPDATE.GCD from the .exe

  Bill

On 08/20/2016 12:54 PM, ael wrote:

On Sat, Jul 30, 2016 at 03:38:30PM -0400, Mark Bradley wrote:

You may be able to locate firmware for your unit at
www.gawisp.com/perry/agree.html.

Thanks again for the suggestion. Unfortunately that is just an archive
of the dumbed down Webupdaters (which assumes particular operating systems)
rather than copies of the real GUPDATE.GCD firmware images.

I assume that the said images files are embedded in the updater files.

Why Garmin haven't left the URI's on their website as before for those
who know how to use them [it isn't hard] defeats me.

It used to be possible to talk to competent people at Garmin support who
actually understood technology. These days I only seem to meet
boneheaded incomprehension :-)

ael

___
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

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

[Bill]

I found a shapefile of the timezones of the world:
http://efele.net/maps/tz/world/


On 06/08/2016 03:17 AM, Colin Smale wrote:


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 Marko, it would be good to have this in OSM. One way of 
doing it would be that the whole state of Indiana gets a "default" 
timezone with exceptions on the level of individual counties, but this 
would require some processing for the use case of "give the current 
UTC offset for this location". I think having a separate system of 
boundary relations (type=boundary, boundary=timezone) would be easier 
to process. But there will be many, many more than just the well-known 
timezones Eastern/Central/Mountain/Pacific/Alaska/Hawaii...


//colin

[1] https://en.wikipedia.org/wiki/Time_in_the_United_States

On 2016-06-08 11:38, Marko Mäkelä wrote:


On Tue, Jun 07, 2016 at 09:36:37PM -0400, greg crago wrote:

I do not know how to add adminstrative boundaries or relations, but it
would be nice if these were added to the USA. INDIANA is divided 
between cities and county boarders. I was just hoping someone had 
done this and I would like to add this info to my maps.


Indiana http://www.openstreetmap.org/relation/161816 does not have a 
timezone=* yet. Maybe someone who is familiar with JOSM and the 
timezones could do this? Because I do not live in the US, I am 
reluctant to change the data myself. But I guess I could do it if 
nobody else steps up, and if you can provide me with a comprehensive 
list of states (counties, cities) and timezones.


You see, I would want this data to be present in OSM, to benefit also 
other users than those using mkgmap-generated maps. If we have the 
data in OSM and if mkgmap starts to interpret it, then you would get 
the timezone borders "out of the box". I do not think that timezone 
borders would add any significant clutter to the map, so IMO they 
should be included in the default style.


Marko
___
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 mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Display of Labels on Maps

[Bill Lancashire]

I have been trying to understand how the display of names and labels on 
map pages is controlled.


I am talking about the following two cases:

a) Labels that appear on the map itself which for the purposes here I 
will call 'Map Labels'.


b) Names which appear in a box at the top of the GPS screen when the 
cursor is placed over an item on the map page which I will refer to as 
'Cursor-Over'  names.



I appreciate the 'Map Label' display is partly controlled by the choice 
of type code for the polygon, line or point, but can this feature in any 
way be controlled by either the style configuration or the TYP file when 
a 'custom' extended code is used?.


Also I would really like to be able to prevent the second feature 
('Cursor-over' name) appearing.  For example, I have line borders for 
polygons on my maps and I want to avoid the name appearing at the top sf 
the screen when the cursor touches the border line.  I have tried with 
no description for the line in the TYP file then I get the word 'line' 
appearing in the top-of-screen box.


Any advice welcome.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] how to use utf-8 in stderr output

[Bill]

Are you sure that your console can display UTF-8 characters? A web 
search turned up this discussion.

http://stackoverflow.com/questions/388490/unicode-characters-in-windows-command-line-how/388500#388500
I am not sure which if any of the solutions described may apply to your 
situation.

  Bill

On 01/14/2015 10:26 AM, Walter Schlögl wrote:

Hi Steve and Gerd,
yes, you got me right. I was talking about stderr output where echo 
messages are printed.

I have tried the following (under Windows):
%JavaPath% -Xmx6144m -ea -jar 
*-Dlog.config=%OptionsPath%\logging_properties.txt*

%ToolPath%\mkgmap\mkgmap.jar  -c %OptionsPath%\%mkgmap_options%
--mapname=%mapid%  --overview-mapname=%overview_mapname%
--family-id=%family_id%  --product-id=%product_id%
--gmapsupp %mkgmap_filename%
%StylesPath%\%StylesFile% *2>>%LogfileName%*
content of logging_properties.txt is:
java.util.logging.FileHandler.encoding=UTF-8
java.util.logging.ConsoleHandler.encoding=UTF-8
I am still getting outputs of echo "name='${name}'” as: ‘??? ??’
if the char set is not part of 1252 (e.g. for greek letters)
I think I did not fully understand your hint with the logging properties.
Walter
*From:* Gerd Petermann <mailto:gpetermann_muenc...@hotmail.com>
*Sent:* Wednesday, January 14, 2015 11:03 AM
*To:* mkgmap-dev@lists.mkgmap.org.uk 
<mailto:mkgmap-dev@lists.mkgmap.org.uk>
*Subject:* Re: [mkgmap-dev] Solution to show transliterated name if no 
other ascii name exists

Hi Walter,

reg. UTF8 in logs:
When I read your post my first question was: Is he talking about the log
that is written to stderr/stdout or the one that is enabled with
java -Dlog.config ... -jar mkgmap.jar ...

I think the latter works fine, the first two look ugly when they write 
to a

windows console. They also look fine when you pipe them to files
like this
java -Dlog.config ... -jar mkgmap.jar ...  > mkgmap.stdout 2>mkgmap.stderr

Gerd

> Date: Wed, 14 Jan 2015 09:15:50 +
> From: st...@parabola.me.uk
> To: mkgmap-dev@lists.mkgmap.org.uk
> Subject: Re: [mkgmap-dev] Solution to show transliterated name if no 
other ascii name exists

>
> Hi Walter,
>
> It's great to hear that it is working well for you. It was just a few
> lines of code, perhaps no one asked before because they imagined it
> would be more difficult.
>
>
> > Do you know, if the logfile can only be written in ANSI coding,
> > or if there is a way to use unicode for logfiles?
>
> I don't know for sure, but make sure you have this included in
> your log.config file.
> java.util.logging.FileHandler.encoding=UTF-8
>
> and try adding this too:
> java.util.logging.ConsoleHandler.encoding=UTF-8
>
> ..Steve
> ___
> 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 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

Re: [mkgmap-dev] A bug ?

[Bill]

Try the command:
"dpkg -l mkgmap"
This should hopefully at least give the debian package version 
information of what you have installed.


It looks the the version is in the form 0.0.0+svn where  after 
the svn is a number that corresponds to the -r number of a mkgmap release.


Looking around on the web, I suspect it will either be 1067 (June 2009) 
or  (August 2014)


Thanks,
  Bill


On 09/15/2014 03:40 PM, Renaud (Ron) OLGIATI wrote:

On Mon, 15 Sep 2014 18:22:43 -0400
"Renaud (Ron) OLGIATI"  wrote:


I am running  --version does not give any version info)gui 1.1 under a debian 
derivative (mkgmap --version does not give any version info)

Please read:

I am running mkgmapgui 1.1 under a debian derivative (mkgmap --version does not 
give any version info)
  
Cheers,
  
Ron.


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] help needed

[Bill]

Gerd,
I tried to confirm a couple of things, and ran out of time, but thought 
the ideas might be of use to you.
1) Are you sure that both the algorithm and JOSM are drawing the same 
line between LAX and JFK.  For example, one could be using a great 
circle route, and the other using a direct heading.  This would result 
in a different distance between A and the line.
2) Have you tried using a two points for the reference line that are 
directly North/South of each other, or on the equator as these should 
result in the reference line being the same regardless of the method of 
determining it.


  Bill

p.s. Thank you, and everyone else who is continuing to improve and 
support mkgmap.



On 07/31/2014 09:41 AM, GerdP wrote:

Hi Andrzej,

thanks for the hints, I'll have a look at them tomorrow. I think
"Spherical versus ellipsoidal model" as a reason is unlikely, the difference
should
be < 1 %, not ~50%
Today I looked at various webpages which calculate the distance between
two points, e.g. airports. It is quite funny how different the results are,
probably because some are using R=6371 km and others 6378.135 m or
values between.

Gerd
  



popej wrote

Hi Gerd,

I have looked at your example file in QGIS and Global Mapper and they
show distance like JOSM. I don't know why there is so big difference. My
guess is that it could be caused by spherical versus ellipsoidal model
of the Earth. Maybe you could test algorithms based on Vincenty's
formulae? See for example:

http://www.gavaghan.org/blog/free-source-code/geodesy-library-vincentys-formula-java/

http://geographiclib.sourceforge.net/html/java/

--
Best regards,
Andrzej
___
mkgmap-dev mailing list
mkgmap-dev@.org
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev





--
View this message in context: 
http://gis.19327.n5.nabble.com/help-needed-tp5813164p5813323.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
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

Re: [mkgmap-dev] small transliteration bug

[Bill]

I've found at least one project using mkgmap that converts 0xF3 to an o 
(and some other in cp1252 that are not ascii characters like 0xD3 to an 
O, 0xED to an i, and probably more) using an external shell script. The 
script also converts letters that are outside of cp1252, and I haven't 
quite figured out how the script is being invoked. I guess it could be 
applied to the OSM data before being sent to mkgmap. There is also a 
script to make all names upper case only, that I am pretty sure gets run 
on the OSM data, and would make sense to run it after the filter command.


General Web Page:
http://www.ggbs.org/index.php/en/Maps.html

Character Conversion:
http://www.ggbs.org/OSM/filter.sh

Force Uppercase:
http://www.ggbs.org/OSM/xmlfilter

Hope this helps,
Bill



On 07/22/2014 02:47 AM, Michał Rogala wrote:


Well, this is an odd case :). Indeed, this letter is part of cp1252 - 
but in case of Polish language, all other diacritical letters (outside 
cp1252 charset) are transliterated except this one. This results in 
situation when user enters city/street name with transliterated 
characters, but index contains non-transliterated letter ó - and the 
search fails.


Would it be possible to provide custom transliteration table/entries 
from a command line argument?


best regards

Michal Rogala


2014-07-22 10:02 GMT+02:00 Steve Ratcliffe <mailto:st...@parabola.me.uk>>:


Hi

latin1 transliteration doesn't touch letter ó (0x00F3) - it
should be
converter to letter o.


Why? The letter is a valid character in cp1252 as far as I know. It
also is displayed in mapsource for me.

..Steve
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk <mailto: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 mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] is tag matching case sensitive?

[Bill]

A search indicates that OSM tags are case sensitive and are expected to 
all be lowercase except for names, example given:
highway=Unclassified needs to be highway=unclassified for it to work 
properly.

http://wiki.openstreetmap.org/wiki/Beginners_Guide_1.4.1

So I believe being case sensitive for OSM tag matching is the proper 
behavior.


  Bill

On 03/17/2014 10:29 AM, GerdP wrote:

Hi Michal,

I think the idea is : "garbage in, garbage out"
If the OSM renderer treats highway=Primary
in the same way as highway=primary,
we should also do that, but I doubt that
this is true.

Gerd


Michał Rogala wrote

thanks for information :). But don't you think that such matching should
be
case insensitive? If by mistake some OSM user creates highway=Primary or
trail with colour=Red such object won't appear in mkgmap compilation.

best regards

Michal Rogala


2014-03-17 15:37 GMT+01:00 GerdP <
gpetermann_muenchen@
>:


Hi Michal,

the tag is evaluated with the java method String.equals(),
so yes, it is case sensitive.

Gerd


Michał Rogala wrote

Hi!

I've always thought that matching tag values is case insensitive. But
today
I found a situation where

colour='#00ff00'

rule doesn't match when tag value is '#00FF00'.

creating a rule (colour='#00ff00' | colour='#00FF00') solved my

problem.

Is it a bug in mkgmap or this kind of matching should by design be case
sensitive? Maybe the hash sign causes trouble somewhere.

best regards

Michal Rogala

___
mkgmap-dev mailing list
mkgmap-dev@.org
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev





--
View this message in context:
http://gis.19327.n5.nabble.com/is-tag-matching-case-sensitive-tp5800033p5800035.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list




___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Copyright text scrambled

[Bill]

I'm not sure if this helps, but I don't think the lines are "scrambled", 
I think the lines are sorted.
I see the lines starting with ".TYP, Any, Attention,Contourlines, 
Database, FOR,Map,Non, OPENSTREETMAP, Thanks"
If it was sorted symbols, caps then lowercase it would match the mapInfo 
you added, with a couple additional lines.
   Bill

On 06/07/2013 07:47 AM, Felix Hartmann wrote:
 > The following change to the mapbuilder.java doesn't seem to work at 
all - it's getting all scrambled in Mapsource (Map Manager - view 
Copyright), anyone got > an idea why?

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Problems searching for California addresses

[Bill]

Summary:  Don't trust cloudmade extracts.

Hopefully one last post on this matter.

After more investigation of other matters, it looks like my problem was 
really in my first step.

Cloudmade uses very aggressive clipping polygons when they do the 
extract.  They are so aggressive they remove bridges and features that 
are close to the coastline.  Turns out most of Alameda County has 
coast-line and the admin_bounds regions get clipped.

Here is a better source that I found:

1) Download california.osm.pbf from geofabrik.de
http://download.geofabrik.de/osm/north-america/us/california.osm.pbf

Using that I can now locally extract the bounds using the steps I 
initially posed (dropping the conversion to pbf).  It lists "United 
States" instead of "United States of America" for the country, but that 
seems reasonable.

Adding "--location-autofill=bounds,is_in" and using a modified the style 
without hamlets are both still necessary.

Thanks again,
   Bill


On 03/04/2012 09:57 PM, Bill wrote:
> Thanks to everyone for your help.
>
> Here is what I have found with styles:
> 1) the "info" file included with the default style is what is causing
> the StackOverflowError.  More specifically the "base-style=" lines.  I
> am not sure from the documentation that I have found what these should be.
>
> 2) the included default style is different from the example default
> style.  I verified that the example default style was identical to the
> default style that is part of the jar file.  I can tell they are
> different because the .img files that are created are very different in
> size.  I have no idea what the differences actually are.
> 47588352 bytes for --style=default
> 38774784 bytes for --style-file=examples/styles/default
> I tried adding the map-features.csv that is part of the jar to the
> example default style which got the size closer
> 43748352 bytes for --style-file=examples/styles/default w/
> map-features.csv
> Again I have no idea what this has added, and or what difference still
> exist between it and the default style.
>
> 3) Ignoring the file size difference.  The examples/styles/default
> appears to function the same with regards to addresses as the default.
> I was able to comment out the hamlet style and it seems to have had the
> same effect as manually deleting all the hamlets.
>
> Here are the steps that seem to result in a reasonable California map
> with address search capability:
>
> 1) Download california.osm.bz2 from cloudmade.com last updated 13
> December 2011
> http://downloads.cloudmade.com/americas/northern_america/united_states/california#downloads_breadcrumbs
>
> 2) Download and unzip boundary file world_*.zip from
> http://www.navmaps.eu/wanmil/ (should automatically end up in a
> directory "bounds")
>
> 3) Use splitter version r200 to create tiled osm.pbf files
> java -Xmx2000m -jar splitter.jar --mapid=63240001 california.osm.bz2
>
> 4) Edit examples/styles/default/points to remove hamlets
> comment the line "place=hamlet [0x0b00 resolution 24]" in your points
> style file
>
> 5) Create Map
> java -Xmx2500m -jar mkgmap.jar --route --remove-short-arcs
> --location-autofill=bounds,is_in --style-file=examples/styles/default
> --index --gmapsupp *.osm.pbf
>
> I'm sure this isn't a perfect solution, but it give vastly superior
> results to either just using bounds (too few cities), or using is_in
> with hamlet information (too many "cities") for California.
>
> Thanks again,
> Bill
>
> ___
> 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

Re: [mkgmap-dev] Problems searching for California addresses

[Bill]

Thanks to everyone for your help.

Here is what I have found with styles:
1) the "info" file included with the default style is what is causing 
the StackOverflowError.  More specifically the "base-style=" lines.  I 
am not sure from the documentation that I have found what these should be.

2) the included default style is different from the example default 
style.  I verified that the example default style was identical to the 
default style that is part of the jar file.  I can tell they are 
different because the .img files that are created are very different in 
size.  I have no idea what the differences actually are.
   47588352 bytes for --style=default
   38774784 bytes for --style-file=examples/styles/default
I tried adding the map-features.csv that is part of the jar to the 
example default style which got the size closer
   43748352 bytes for --style-file=examples/styles/default w/ 
map-features.csv
Again I have no idea what this has added, and or what difference still 
exist between it and the default style.

3) Ignoring the file size difference.  The examples/styles/default 
appears to function the same with regards to addresses as the default.  
I was able to comment out the hamlet style and it seems to have had the 
same effect as manually deleting all the hamlets.

Here are the steps that seem to result in a reasonable California map 
with address search capability:

1) Download california.osm.bz2 from cloudmade.com last updated 13 
December 2011
http://downloads.cloudmade.com/americas/northern_america/united_states/california#downloads_breadcrumbs

2) Download and unzip boundary file world_*.zip from 
http://www.navmaps.eu/wanmil/ (should automatically end up in a 
directory "bounds")

3) Use splitter version r200 to create tiled osm.pbf files
java -Xmx2000m -jar splitter.jar --mapid=63240001 california.osm.bz2

4) Edit examples/styles/default/points to remove hamlets
comment the line "place=hamlet [0x0b00 resolution 24]" in your points 
style file

5) Create Map
java -Xmx2500m -jar mkgmap.jar --route --remove-short-arcs 
--location-autofill=bounds,is_in --style-file=examples/styles/default 
--index --gmapsupp *.osm.pbf

I'm sure this isn't a perfect solution, but it give vastly superior 
results to either just using bounds (too few cities), or using is_in 
with hamlet information (too many "cities") for California.

Thanks again,
   Bill

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Problems searching for California addresses

[Bill]

Great I will try that, I wasn't sure that would affect addressing.
Unfortunately I am having trouble with using the included 
example/styles/default in r2227 with no modifications.
I copied the entire contents of examples/styles/default to stylesdefault 
and added --style-file=defaultstyle to my command and get a 
StackOverflowError

java -Xmx2500m -jar mkgmap.jar --route --remove-short-arcs 
--add-pois-to-areas --location-autofill=bounds,is_in --index --gmapsupp 
--style-file=defaultstyle *.osm.pbf

java.lang.StackOverflowError
 at java.io.UnixFileSystem.getBooleanAttributes0(Native Method)
 at 
java.io.UnixFileSystem.getBooleanAttributes(UnixFileSystem.java:243)
 at java.io.File.isDirectory(File.java:771)
 at 
uk.me.parabola.mkgmap.osmstyle.StyleFileLoader.createStyleLoader(StyleFileLoader.java:55)
 at 
uk.me.parabola.mkgmap.osmstyle.StyleImpl.(StyleImpl.java:132)
 at 
uk.me.parabola.mkgmap.osmstyle.StyleImpl.readBaseStyle(StyleImpl.java:518)
 at 
uk.me.parabola.mkgmap.osmstyle.StyleImpl.(StyleImpl.java:140)
...(Previous 2 lines repeated many times)
Exiting - if you want to carry on regardless, use the --keep-going option

Thanks,
   Bill

On 03/04/2012 12:18 AM, Carlos Dávila wrote:
> If you don't want to have hamlets in your map, you can simply remove or
> comment the line "place=hamlet [0x0b00 resolution 24]" in your points
> style file. If you want to keep hamlets, but don't have them in the
> cities index, you can change the type 0x0b00 to a different one not
> searchable.
>

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Problems searching for California addresses

[Bill]

Henning,
I appreciate the info on additional options for location-autofill.

Adding "--location-autofill=bounds,is_in" to my command I discovered 
that it will now pull city type information from the .osm file as well 
as from the bounds directory.  Unfortunately there are a crazy amount of 
"hamlets" that are part of the OSM database and are not generally 
referred to as the city in an address.

I found a smaller extract of the sf-bay-area 
(http://metro.teczno.com/#sf-bay-area) which includes Fremont which I am 
most interested in, and manually deleted every node, way and relation 
that was a hamlet.  When I reprocess this and load it into my device, it 
passes all my quick spot checks that have failed before.

I started looking at the default style rules to try and figure out if I 
could see how to disable hamlets, but all I see are admin_level* rules 
and there is no admin_level explicitly set on the hamlets.  Is there a 
place I can look to find this mapping or does "is_in" add city 
information via another mechanism?

Are the style rules the correct way to attack this, or should I be 
looking at pre-filtering the osm file using osmconvert or osmosis?  It 
would seem that if new style rules could be devised then everyone else 
who tries to do this will get the automatic gain.  Filtering would seem 
to just make it work for me.

Thanks,
   Bill


On 03/03/2012 12:13 AM, Henning wrote:

>  Hi, I think you should have something like this in your mkgmap-call:
>
>  --location-autofill=bounds,is_in,nearest --index --bounds=data\bounds
>
>  Henning


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Problems searching for California addresses

[Bill]

Gerd,
Thanks for the quick reply.  That makes complete sense that a California 
extract wouldn't have information about a larger area that it is part 
of.  I'm not sure why it resolved having ABC instead of actual county 
information, but it seems to have done that as well.

I've replaced steps 3, 5 and 6 with downloading and extracting bounds 
information:
http://www.navmaps.eu/wanmil/world_20120221.zip

That seems to resolve issue 1) and 4). It now shows United States of 
America and all the cities I've seen have a reasonable county listed.

Which leaves:
2) some cities not showing up.  Examples Oakland (Major California City) 
and Fremont (Where I live)
3) some addresses associated with an incorrect city.  Example Fremont 
addresses are associated with Livermore.

Further Information:
Of all the cities in Alameda County, only Livermore seems to be present.
[Alameda, Albany, 
Berkeley,Dublin,Emeryville,Fremont,Irvington,Hayward,Newark,Oakland,Piedmont,Pleasanton,San
 
Leandro,Union City]
I was hoping that everything in Alameda County was now in Livermore, but 
locations in Oakland are in San Francisco.  And locations in Albany are 
in Richmond.
I've been able to find all of the Cities in Alameda except for Fremont 
and Irvington in this file:
bounds_175_-570.bnd
Since it is a binary file, I'm not quite sure what it says about them.
Also it would appear that in Contra Costa County at least 2 cities 
Concord and Martinez are present, many others in Contra Costa are missing.

Thanks,
   Bill


On 03/02/2012 09:51 PM, GerdP wrote:
> Hello Bill,
>
> some of the problems are caused by the fact that you use the california.o5m
> to create the
> bounds for california. This extract probably doesn't contain any usable
> information about admin_level=2 boundaries like "USA".
> You should either use a larger extract (e.g. north america)  to create the
> bounds or download
> the precompiled boundaries created by WanMil:
>
> http://www.navmaps.eu/wanmil/
>
> Please try that first.
>
> Gerd
>
>
> Bill wrote
>> I've been using mkgmap to compile a California map for my Garmin for a
>> while now, and was excited to see that addressing was being supported,
>> but I'm having troubles getting this new feature to work as I expect.
>>
>> System Information:
>> OS: 64-bit Ubuntu 11.10
>> GPS: Garmin Montana 650 software version 3.80
>>
>> These are the steps I have taken:
>> 1) Download california.osm.bz2 from cloudmade.com last updated 13
>> December 2011
>> http://downloads.cloudmade.com/americas/northern_america/united_states/california#downloads_breadcrumbs
>>
>> 2) Use osmconvert version 0.5Z to convert to pbf
>> bzcat california.osm.bz2 | ./osmconvert32 - -o=california.pbf
>>
>> 3) Use osmconvert version 0.5Z to convert to o5m
>> ./osmconvert32 california.pbf -o=california.o5m
>>
>> 4) Use splitter version r200 to create tiled osm.pbf files
>> java -Xmx2000m -jar splitter.jar --mapid=63240001 california.pbf
>>
>> 5) Use osmfilter version 1.2M to create california-boundaries.osm
>> ./osmfilter32 california.o5m --keep-nodes=
>> --keep-ways-relations="boundary=administrative =postal_code
>> postal_code=">  california-boundaries.osm
>>
>> 6) Use mkgmap version r2227 to create bounds directory
>> java -Xmx2500M -jar mkgmap.jar
>> --createboundsfile=california-boundaries.osm
>>
>> I get the following printouts, but I don't believe them to be critical:
>> SEVERE (BoundarySaver): Calculate bbox to
>> (32.18650817871094,-124.45449829101562) to
>> (41.84246063232422,-114.79854583740234)
>> SEVERE (BoundarySaver): Calculate bbox to
>> (32.18650817871094,-124.45449829101562) to
>> (41.84246063232422,-114.79854583740234)
>>
>> 7) Use mkgmap version r2227 to create gmapsupp.img file from the tiles
>> and bounds directory
>> java -Xmx2500m -jar mkgmap.jar --route --remove-short-arcs
>> --add-pois-to-areas --index --gmapsupp *.osm.pbf
>>
>> This creates a valid Garmin map image that loads and displays map
>> information on the device as expected, however I notice the following
>> when trying to search for addresses on the Garmin Montana:
>> 1) The only Country I can select is "Country", not USA or United States
>> of America
>> 2) City names hit and miss.  "San Francisco" shows up as "San Francisco,
>> ABC" but "Sacramento" isn't found.
>> 3) Some addresses have incorrect city information, for example address
>> that should be in "Fremont, Alameda County" are showing up under
>> "Livermore, ABC".
>> 4) Only so

[mkgmap-dev] Problems searching for California addresses

[Bill]

I've been using mkgmap to compile a California map for my Garmin for a 
while now, and was excited to see that addressing was being supported, 
but I'm having troubles getting this new feature to work as I expect.

System Information:
OS: 64-bit Ubuntu 11.10
GPS: Garmin Montana 650 software version 3.80

These are the steps I have taken:
1) Download california.osm.bz2 from cloudmade.com last updated 13 
December 2011
http://downloads.cloudmade.com/americas/northern_america/united_states/california#downloads_breadcrumbs

2) Use osmconvert version 0.5Z to convert to pbf
bzcat california.osm.bz2 | ./osmconvert32 - -o=california.pbf

3) Use osmconvert version 0.5Z to convert to o5m
./osmconvert32 california.pbf -o=california.o5m

4) Use splitter version r200 to create tiled osm.pbf files
java -Xmx2000m -jar splitter.jar --mapid=63240001 california.pbf

5) Use osmfilter version 1.2M to create california-boundaries.osm
./osmfilter32 california.o5m --keep-nodes= 
--keep-ways-relations="boundary=administrative =postal_code 
postal_code=" > california-boundaries.osm

6) Use mkgmap version r2227 to create bounds directory
java -Xmx2500M -jar mkgmap.jar --createboundsfile=california-boundaries.osm

I get the following printouts, but I don't believe them to be critical:
SEVERE (BoundarySaver): Calculate bbox to 
(32.18650817871094,-124.45449829101562) to 
(41.84246063232422,-114.79854583740234)
SEVERE (BoundarySaver): Calculate bbox to 
(32.18650817871094,-124.45449829101562) to 
(41.84246063232422,-114.79854583740234)

7) Use mkgmap version r2227 to create gmapsupp.img file from the tiles 
and bounds directory
java -Xmx2500m -jar mkgmap.jar --route --remove-short-arcs 
--add-pois-to-areas --index --gmapsupp *.osm.pbf

This creates a valid Garmin map image that loads and displays map 
information on the device as expected, however I notice the following 
when trying to search for addresses on the Garmin Montana:
1) The only Country I can select is "Country", not USA or United States 
of America
2) City names hit and miss.  "San Francisco" shows up as "San Francisco, 
ABC" but "Sacramento" isn't found.
3) Some addresses have incorrect city information, for example address 
that should be in "Fremont, Alameda County" are showing up under 
"Livermore, ABC".
4) Only some County names are showing up.  "Ontario, Riverside Country" 
others like "San Francisco" show up as ABC.

Any ideas on where these problems are occurring?  I can search on 
openstreetmap.org and it appears to have the correct information as far 
as city, county and country, but I beyond that I haven't figured out how 
to verify when and where the data is correct or not.

Thanks,
   Bill



___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Question about Resolutions in Default Style.

[Bill Lancashire]

I would like to understand a few statements in the default mkgmap style:

The default 'option' file defines resolutions as:
levels = 0:24, 1:22, 2:20, 3:18, 4:16.

Yet in 'polygons' file the following line exists:
natural=sea [0x32 resolution 10]

and in 'lines' file the following line exists;
natural=coastline [0x15 resolution 12]

Do these lines have the same effect in this style as the following:
natural=sea [0x32 resolution 16]
natural=coastline [0x15 resolution 16]
or is there a subtle difference?.


Also, in the 'lines' file the following statement exists:
highway=* & area!=yes [0x07 ]

Is the effect of a match to draw [0x07] at ALL resolutions?

Thanks,

Bill.


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Preventing Routing Node Creation

[Bill Lancashire]

michael lohr wrote:

1. what do you mean by desirable rendering features?
Certainly on my devise (GPSMAP 62s), where a road having one of the 
standard default Garm,n routable codes makes a junction with a road 
having a custom 'extended' type code then the former 'pushes into the 
latter making the result rather unsightly.


I am wanting  to use one of the 'routable' standard codes to draw the 
roundabouts with an 'overlay'.  However, as I already have the 
roundabout code (0x0c) in invisible form on the same region of road I 
want the overlay to be non-routable otherwise there will be two routable 
lines in the same place in the same layer.


Bill.





Am 19.07.2011 13:39, schrieb Bill Lancashire:

Many thanks for your suggestions.

!.  I want to use the code because of it's desirable rendering 
features compared to an extended type of code.


2.  I've thought about this one, but does it prevent routing by any 
means?.  I guess the routing nodes will still be formed.


Bill.

michael lohr wrote:

two solutions come to mind:

1. use a non-routable code

2. highway=* {set access=no} [0xXX]



Am 19.07.2011 11:45, schrieb Bill Lancashire:
Please excuse me coming to this mailing list with a 'beginners' question 
but, believe me, I have searched widely without a solution.


I would like to know if is possible in a 'routing generation' compile to 
have a command in the style 'lines' file which will prevent creation of 
routing nodes completely for a specific code for which such nodes would 
normally be created.


For example can something like this be used:

highway=* {add mkgmap:abxdef-ghj=false}[0xXX]

Where 0xXX is the routable Garmin code.

Thanks for any guidance.

Bill.
___
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 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 mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Preventing Routing Node Creation

[Bill Lancashire]

Many thanks for your suggestions.

!.  I want to use the code because of it's desirable rendering features 
compared to an extended type of code.


2.  I've thought about this one, but does it prevent routing by any 
means?.  I guess the routing nodes will still be formed.


Bill.

michael lohr wrote:

two solutions come to mind:

1. use a non-routable code

2. highway=* {set access=no} [0xXX]



Am 19.07.2011 11:45, schrieb Bill Lancashire:
Please excuse me coming to this mailing list with a 'beginners' question 
but, believe me, I have searched widely without a solution.


I would like to know if is possible in a 'routing generation' compile to 
have a command in the style 'lines' file which will prevent creation of 
routing nodes completely for a specific code for which such nodes would 
normally be created.


For example can something like this be used:

highway=* {add mkgmap:abxdef-ghj=false}[0xXX]

Where 0xXX is the routable Garmin code.

Thanks for any guidance.

Bill.
___
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 mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Preventing Routing Node Creation

[Bill Lancashire]

Please excuse me coming to this mailing list with a 'beginners' question 
but, believe me, I have searched widely without a solution.

I would like to know if is possible in a 'routing generation' compile to 
have a command in the style 'lines' file which will prevent creation of 
routing nodes completely for a specific code for which such nodes would 
normally be created.

For example can something like this be used:

highway=* {add mkgmap:abxdef-ghj=false}[0xXX]

Where 0xXX is the routable Garmin code.

Thanks for any guidance.

Bill.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Problem Displaying Polygons with Extended Type codes

[Bill Lancashire]

Charlie,

Thank you for providing the download links.

They were very useful. After many rebuilds and recombination's of the 
TYP file split from your gmapsupp.img with my compiles I found the 
problem. It was a 'beginners' mistake on my part. I had been saving my 
TYP files with the 'OLD' Header format which meant that the drawing 
orders of the extended-code polygon types were somehow very messed up.


No problem therefore with display of extended polygon codes on the 
Garmin GPSMAP62s.


Thanks for the help.

Bill.

Charlie Ferrero wrote:

On 04/07/2011 12:50, Bill Lancashire wrote:
  

Charlie, thanks for your response.

I have been doing a few controlled tests and I am now fairly sure that
it is the GPSMap62s that will not display the 'extended' polygon codes.

What I did was to compile a map using the 'default' style with r1979
together with a very simple TYP defining only 'leisure=playground [0x24
resolution 24]' (at draw level 7). This displayed correctly.

Then I simply edited the 'polygons' file line to read
'leisure=playground [0x10103 resolution 24]' and suitably changed the
TYP. In this case the polygon was NOT displayed. In both cases I used
only the minimal arguments in the mkgmap compile command line.

I will try to put a small GMAPSUPP.IMG online somewhere for others to
confirm.

Conversely, it would be good if I could test a build that someone else
has made using an extended polygon code.

Bill.



You can download a gmapsupp.img from
http://www.cferrero.net/maps/gcc_downloads.html
that includes lots of extended type polygons (land background, 
archeological sites, woods, gardens etc).


You can get the TYP that is used here:
http://www.cferrero.net/maps/map_downloads.html

--
Charlie
___
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

Re: [mkgmap-dev] Problem Displaying Polygons with Extended Type codes

[Bill Lancashire]

Charlie, thanks for your response.

I have been doing a few controlled tests and I am now fairly sure that 
it is the GPSMap62s that will not display the 'extended' polygon codes.


What I did was to compile a map using the 'default' style with r1979 
together with a very simple TYP defining only 'leisure=playground [0x24 
resolution 24]' (at draw level 7). This displayed correctly.


Then I simply edited the 'polygons' file line to read 
'leisure=playground [0x10103 resolution 24]' and suitably changed the 
TYP. In this case the polygon was NOT displayed. In both cases I used 
only the minimal arguments in the mkgmap compile command line.


I will try to put a small GMAPSUPP.IMG online somewhere for others to 
confirm.


Conversely, it would be good if I could test a build that someone else 
has made using an extended polygon code.


Bill.


Charlie Ferrero wrote:

On 29/06/2011 01:57, Bill Lancashire wrote:
  

I have recently noticed that polygons assigned codes of the type 0x101xx
are not displayed on my Garmin 62s. However, if I open the compiled maps
in a package such as GPSMapEdit I can see that the features are indeed
compiled correctly in the maps.

I am using version r1973
The polygons are correctly defined in a TYP file
If I redefine the polygons to alternative unused codes of type 0x2x or
0x3x and also change the code in the TYP file then the polygons are
displayed correctly.

It does not seem to matter what the Drawing Level is in the TYP file.
Non of the 0x101xx types are ever displayed.

In the case of Polylines, I have used several codes of the types
0x100xx, 0x101xx and 0x105xx and they are displayed correctly.

I am really puzzled by this and would really appreciate any insight into
what is happening.

At the lower drawing levels in the TYP file I have the following defined:

Type *0x4b* [*Background (coverage)*], Drawing order: *1

*Type *0x32* [*Sea*], Drawing order: *2 (Placeholder only)

*Type *0x27* [*?*], Drawing order: *3 **(Placeholder only)

*Then follows Drawing Level 4 with codes 0x02, 0x03 etc.

Any ideas on this please?.


Bill,

If you can post a link to a small gmapsupp.img file (including your 
TYP), we can try it on our own devices and see if this is a "feature" of 
the GPSMap62s, or if there's something else wrong in your compile.


Charlie
___
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] Problem Displaying Polygons with Extended Type codes

[Bill Lancashire]

I have recently noticed that polygons assigned codes of the type 0x101xx 
are not displayed on my Garmin 62s.  However, if I open the compiled 
maps in a package such as GPSMapEdit I can see that the features are 
indeed compiled correctly in the maps.


I am using version r1973
The polygons are correctly defined in a TYP file
If I redefine the polygons to alternative unused codes of type 0x2x or 
0x3x and also change the code in the TYP file then the polygons are 
displayed correctly.


It does not seem to matter what the Drawing Level is in the TYP file.  
Non of the 0x101xx types are ever displayed.


In the case of Polylines, I have used several codes of the types 
0x100xx, 0x101xx and 0x105xx and they are displayed correctly.


I am really puzzled by this and would really appreciate any insight into 
what is happening.


At the lower drawing levels in the TYP file I have the following defined:

Type *0x4b* [*Background (coverage)*], Drawing order: *1

*Type *0x32* [*Sea*], Drawing order: *2 (Placeholder only)

*Type *0x27* [*?*], Drawing order: *3 **(Placeholder only)

*Then follows Drawing Level 4 with codes 0x02, 0x03 etc.

Any ideas on this please?.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Syntax Question

[Bill Lancashire]

Could someone explain to me the correct way  and position to use the (!) 
in the style files.

For example, in the current 'default style' the following two lines exist:

railway=rail & !(tunnel=yes) [0x14 resolution 21]

leisure=track & area!=yes

What is the significance of putting the (!) before the open brackets or 
before the (=) sign.

I mean, would there be any difference between the following two 
statements and would they both work?:

railway=rail & !(tunnel=yes)

railway=rail & tunnel!=yes

Many thanks.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Can Extra Resolutions be Implemented

[Bill Lancashire]

It is clear when zooming in on my GPSMAP 62s that Garmin can make use of 
resolutions greater than 24 with regard to 'styling':


I have a map in which I go with the default 'styling' for 'Residential 
Roads (0x06)' by not specifying this in my TYP file.  I zoom-in to the 
point where I know that level=0 (resolution 24) is displayed and then 
when I zoom-in further, the thickness of the 0x06 road in the Garmin 
style definitely gets increases.  I can clearly see this if examine with 
or without a magnifying glass on the screen.  So Garmin have definitely 
got a way to extend their variation of line thickness's beyond the 
resolution 24 level that is available for us to configure with mkgmap.


This maybe something new implemented on the newer Garmin GPS devices 
that have higher resolution screens.  Can mkgmap be extended so that the 
user can specify styles to appear when zoomed-in over resolution 24 like 
Garmin do?.

/*
Bill.*/

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Control of Anti-aliasing in Lines

[Bill Lancashire]

If I create a line of example width 1px as a 'bitmap' it is not 
'anti-aliased' when displayed on the Garmin (GPSMAP 62s).  However, if 
the 1px line is created as 'line only' on the TYP editor, then the line 
is 'anti-aliased' and therefore appears thicker at lower zoom levels.  
This anti-aliasing can be seen if the screen is examined with a 
magnifying glass.

My question is 'can this anti-aliasing be controlled?.  For example, 
could one create a complex  pattern line as a bitmap and have it 
'anti-aliased' as presently I don't see a way to do this?.

Bill.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Tile Border Artifact with --generate-sea

[Bill Lancashire]

WanMil,

Many thanks.

I have a little further information:

If I examine the screen on my GPS with a magnifying glass near to the 
'thin blue line' artefact, where a road crosses this line there is an 
artefact crossing the road line also. However this is NOT directly in 
line with the 'blue' line and is orthogonal to the road. By this I mean 
that the artefact across the road is perpendicular to the road direction 
and therefore not parallel to the 'blue line along the tile boundary.


I hope this is clear and we can find a solution to this.

Bill.

WanMil wrote:

I have just noticed 'thin blue line' (I estimate about 1 pixel wide)
along every tile edge )or border).  This is more obvious when I 'zoom
out' and it highlights my tiles because there is this blue sea-coloured
border around them.

I am using the Geofabrik GB OSM download and my relevant compile line is:
--generate-sea:no-mp, extend-sea-sectors, close-gaps=1.

Currently using mkgmap version 1827

Has this been seen before and Is there a setting for me to avoid this?.

  

Just a bit more information:

Strangely, I can see the blue lines at the tile borders on my
  Garmin GPSMAP 62s but NOT on the Etrex Legend HcX of my Wife.  This is
using the exact same TYP file.

On examining the screen with magnifier it seems that the lines are 2 pixels
  wide
so I guess this is a one-pixel 'sea' border added to each tile boundary.

Any ideas?.




Bill,

I have an idea. The sea bounds are made one or two long/lats larger than 
the tile borders. Maybe that's the cause for it.

I will investigate it and post about my results.

WanMil
___
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

Re: [mkgmap-dev] Tile Border Artifact with --generate-sea

[Bill Lancashire]

flabot  googlemail.com  googlemail.com> writes:

> 
> you use http://dev.openstreetmap.de/aio/africa-daily/ ?
> 


I do not understand your brief reply.

This is where I download the OSM files for Great Britain:

http://download.geofabrik.de/osm/europe/

Are you suggesting this source may be the problem for me?



___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Tile Border Artifact with --generate-sea

[Bill Lancashire]

Bill Lancashire  o2.co.uk> writes:

> 
> I have just noticed 'thin blue line' (I estimate about 1 pixel wide) 
> along every tile edge )or border).  This is more obvious when I 'zoom 
> out' and it highlights my tiles because there is this blue sea-coloured 
> border around them.
> 
> I am using the Geofabrik GB OSM download and my relevant compile line is:
> --generate-sea:no-mp, extend-sea-sectors, close-gaps=1.
> 
> Currently using mkgmap version 1827
> 
> Has this been seen before and Is there a setting for me to avoid this?.
> 

Just a bit more information:

Strangely, I can see the blue lines at the tile borders on my
 Garmin GPSMAP 62s but NOT on the Etrex Legend HcX of my Wife.  This is
using the exact same TYP file.

On examining the screen with magnifier it seems that the lines are 2 pixels
 wide
so I guess this is a one-pixel 'sea' border added to each tile boundary.

Any ideas?.




___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Tile Border Artifact with --generate-sea

[Bill Lancashire]

I have just noticed 'thin blue line' (I estimate about 1 pixel wide) 
along every tile edge )or border).  This is more obvious when I 'zoom 
out' and it highlights my tiles because there is this blue sea-coloured 
border around them.

I am using the Geofabrik GB OSM download and my relevant compile line is:
--generate-sea:no-mp, extend-sea-sectors, close-gaps=1.

Currently using mkgmap version 1827

Has this been seen before and Is there a setting for me to avoid this?.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Showing coastline with --generate-sea

[Bill Lancashire]

Bill Lancashire  o2.co.uk> writes:

> 
> There was a mention some months ago during the active development of 
> 'sea' generation that when '--generate-sea:no-mp' was used 
> 'natural=coastline' cannot be displayed.
> 
> I understand that a patch was developed to reinstate this.  Can this 
> patch now be landed on the development 'trunck'.
> 
> Bill.
> 

My temporary solution to this issue has been to create an additional map layer
containing ONLY the element 'natural=coastline' and giving this layer a priority
higher than the main 'base layer' but lower than the 'contours' layer.  It seems
to work well but a patched mkgmap to overcome this problem would be better.


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Showing coastline with --generate-sea

[Bill Lancashire]

Charlie Ferrero  cferrero.net> writes:

> 
> On 22/02/2011 23:50, WanMil wrote:
> > Hi Bill,
> >
> > which patch do you mean? Can you give a link to it?
> >
> > WanMil
> >
> This might be what he's referring to:
> http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2010q1/007920.html
> 


Yes, that looks like the one, although in the thread referred to, I think that
'--generate-coastline' should read '--generate-sea'.

I have no experience of compiling Windows programs from source code so cannot
try the patch myself.  Are there any archived builds that contain this patch I
could try?.

Bill.

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Showing coastline with --generate-sea

[Bill Lancashire]

There was a mention some months ago during the active development of 
'sea' generation that when '--generate-sea:no-mp' was used 
'natural=coastline' cannot be displayed.

I understand that a patch was developed to reinstate this.  Can this 
patch now be landed on the development 'trunck'.

Bill.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev