Hi
I've been using --generate-sea rather than --precomp-sea for a few
weeks and there doesn't seem to be an obvious performance penalty and
the img size is slightly better (but I have been changing other things
along the way).
However - It doesn't seem to know about the rule that land must be on
patch.
>
> Gerd
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Dienstag, 14. März 2017 10:53:43
> An: mkgmap-dev@lists.mkgmap.org.uk
> Betreff: Re: [mkgmap-dev] [Patch v1] differet Coord implementation
>
> H
Are you looking at the highest (24) resolution? My device (Etrex
legend) has its own ideas of when to start showing elements as you zoom
in, regardless of the map definition.
and the default _drawOrder for most shapes appears to be 2 but some are
1 and 0.
Ticker
On Tue, 2017-03-14 at 09:35 -0800
Hi
I'd have thought the most common use of this feature is to have
different types for different resolutions/road attributes/etc ie:
junction=roundabout & (highway=trunk | highway=trunk_link)
[0x10801 resolution 18 - 23 default_name "name1"]
[0x0c road_class=4 road_speed=2 resolution 24 def
I have this in my style - as a change from default style- works nicely:
#RWB barrier=bollard | barrier=bus_trap | barrier=gate [0x660f
resolution 24]
#RWB barrier=block | barrier=cycle_barrier | barrier=stile |
barrier=kissing_gate [0x660f resolution 24]
#RWB get lots of Unnamed Pillar.
#RWB Also
sing memory and IMG size
Ticker
On Tue, 2017-03-28 at 05:26 +, Gerd Petermann wrote:
> Hi Ticker,
>
> can you explain this a bit, please?
> I don't understand what RW8 means, but it seems that you have many
> named barriers in your area?
>
> Gerd
>
Hi Gerd
I think your fix will remove most of the benefits of the
PredictFilterPoints, by keeping all original map coords.
My mistake was assuming that only original points were candidates for
preserving but this looks not to be true. It looks like housenumber
processing generates points to be kept
at || lon != lastLon
> ||
> (checkPreserved && (p instanceof
> CoordNode || p.preserved(
> I was not sure if we have a case where a CoordNode doesn't return
> true for a call of p.preserved(), so I kept that.
>
> Gerd
> __
Hi
A few thoughts on this:
Should it be a style invoked function.
Can the prefixes and suffixes be country defined and selected by, say,
admin boundary. Is there already a place where mkgmap has country
dependent info (like drive-on=)?
I used to live on "Avenue Road" - slight care needs to be t
word between 0x1e and 0x1f.
>
> Gerd
> ________
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Mittwoch, 12. April 2017 13:12:41
> An: mkgmap-dev@lists.mkgmap.org.uk
> Betreff: Re: [mkgmap-dev] How can we use prefix/suffix feature in
> road name
Hi
I had suspicions that the line:
amenity=restaurant & cuisine ~ '.*pizza.*' [0x2a0a resolution 24]
doesn't work, but never bother looking in detail. It would fall through
to:
amenity=restaurant & cuisine=* [0x2a13 resolution 24]
There is a slight reason to use a subtype when cuisine is speci
Hi
Not on my etrex, the last defined subtype is 0x2b12 = Speciality Food
Products, then 13 onwards are 'Other'
If some garmin devices do understand more beyond 0x12 in a consistent
way, can they be added to the default style and the catchall then use a
value a few beyond that.
Ticker
On Thu, 2
Hi
Tested this on Etrex Legend HCx (software 3.2)
On Wed, 2017-05-17 at 08:56 +, Gerd Petermann wrote:
> Hi all,
>
> I've uploaded a small test map that shows the problem on my Oregon
> 600 with firmware 5.00:
> http://files.mkgmap.org.uk/download/353/gmapsupp.img
>
> Please test what your
Hi
I have point items (actually postcodes) that I want to be able to find
with the Find>Address function. These are not normally on a street, but
I have a street name as a point tags that I want to use and standard
mkgmap:admin_level processing provides the city, region and country.
Having them a
tores address info in a format that is similar
> to
> an addr:interpolation=* way along a road.
>
> Gerd
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Dienstag, 6. Juni 2017 17:59:19
> An: mkgmap development
>
de is used for the make-poi-index option. I believe that this
> index is completely obsolete, but maybe
> the Etrex uses it.
> Gerd
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Mittwoch, 7. Juni 2017 11:51:27
&
Hi Gerd
I've just downloaded the latest splitter (r583) and using it on british
-isles-latest.osm.pbf (downloaded 10-Mar-2017) with
--geonames-file=../cities15000.zip
It now names one of the maps as BE-Brugge!
Brugge is just on the right-hand side of the map (although not, because
it has been r
ith other things during the summer, so I have no time
> to
> analyse it in detail.
>
> Gerd
>
> ____
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Donnerstag, 8. Juni 2017 10:39:45
> An: mkgmap-dev@lists.mkgmap.org
Quick thought - this caught me out with ferries - have you requested
"No Toll Roads" in routing. In openStreetMap, some ferry routes
explicitly say toll=yes/no and some don't bother saying anything, and I
think the default style then doesn't mark it as toll - but I think it
would be better if it di
Hi all
For United Kingdom I suggest:
suffix:en = " Avenue", " Close", " Court", " Crescent", " Drive",
" Gate", " Grove", " Lane", " Mews", " Parade", " Place", " Road",
" Square", " Street", " Terrace", " View", " Way"
Having:
prefix1:en = "North ", "East ", "South ", "West "
is not a goo
The ShapeSplitter code looks like my mistake - I suspect it should be
testing the lowPoint and highPoint, but need to think about this more
carefully before committing myself.
HousenumberGenerator not mine but - yes, looks like those 2 lines
should be removed
ShapeMergeFilter isn't mine, but loo
I have a strange problem.
With a particular split of 'british-isles', one map from the split
causes the list of cities in the Find>Address function to be empty.
Find>Address does still find streets, but not this is not very useful
when cannot limit by City first.
Excluding this particular map bu
Hi Gerd
Attached is patch for ShapeSplitter
Ticker
On Sat, 2017-07-15 at 19:40 +0100, Ticker Berkin wrote:
> The ShapeSplitter code looks like my mistake - I suspect it should be
> testing the lowPoint and highPoint, but need to think about this more
> carefully before committi
"la"
> > and "el" suffixes for portuguese (can be added to local files by
> > anyone
> > who want to use them) and removal of English prefixes, which may
> > need
> > some more discussion. Please check if I missed something and
> > comment
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Mittwoch, 26. Juli 2017 12:12:36
> An: mkgmap-dev@lists.mkgmap.org.uk
> Betreff: Re: [mkgmap-dev] Strange code in mkgmap?
>
> Hi Gerd
>
> Attached is patch for ShapeSplitter
>
> Ticker
>
>
problem and I should
pursue this line, or could it be unreliable and this exception is due
to it rather than the format of the index?
Thanks
Ticker
On Wed, 2017-07-26 at 23:42 -0700, Gerd Petermann wrote:
> Ticker Berkin wrote
> > With a particular split of 'british-isles'
maps.
writer.putChar((char) cityIndex);
else
writer.put((byte) cityIndex);
}
There were more than 63335 cities in the failing map.
Ticker
On Sat, 2017-07-29 at 16:09 +0100, Ticker Berkin wrote:
> Hi Gerd
>
> I've done a bit o
ities. Do you "abuse" the corresponding POI
> for something?
>
> Gerd
> ________
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Samstag, 29. Juli 2017 18:13:20
> An: mkgmap-dev@lists.mkgmap.org.uk
> Betreff: Re: [
> thanks for the patch. I seem to remember that the number of entries
> in mdr5 is also used
> elsewhere. Will have a closer look tomorrow.
>
> Gerd
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Samstag
t; Maybe there is another problem caused by the high number of cities.
> Maybe you can post a link to the tile with
> that high number?
>
> Gerd
>
> ________
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Samstag, 29. Juli
think?
Regards
Ticker
On Sun, 2017-07-30 at 10:16 +0100, Ticker Berkin wrote:
> Hi Gerd
>
> I'll just done a bit more investigation and see what seems to be the
> the same assumption in imgfmt/app/net/RoadDef.java around line 296
>
_
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Montag, 31. Juli 2017 13:09:49
> An: mkgmap-dev@lists.mkgmap.org.uk
> Betreff: Re: [mkgmap-dev] Find Address - No cities
>
> Hi Gerd
>
> I started fixing all the places where there is an assumption a
______
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Dienstag, 1. August 2017 14:31:57
> An: mkgmap-dev@lists.mkgmap.org.uk
> Betreff: Re: [mkgmap-dev] Find Address - No cities
>
> Hi Gerd
>
> I decided to both fix the code a
___
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Donnerstag, 3. August 2017 10:07:30
> An: mkgmap-dev@lists.mkgmap.org.uk
> Betreff: Re: [mkgmap-dev] Find Address - No cities
>
> Hi Gerd
>
> Sorry - I did do "ant test",
1101 - 1134 of 1134 matches
Mail list logo
