> Von: mkgmap-dev im Auftrag
> von Lorenzo Mastrogiacomi
> Gesendet: Sonntag, 6. Januar 2019 17:46
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] default style improvements
>
> Il giorno dom, 06/01/2019 alle 12.45 +, Ticker Berkin ha s
000, Ticker Berkin ha scritto:
> > Hi Lorenzo
> >
> > I know that the OSM definition says square should have area=yes,
> > but
> > I
> > find a vast number where there is no area tag and they seem to be
> > square/piazza, eg
> >
Hi Gerd
see embedded answers
Regards
Ticker
On Sun, 2019-01-06 at 09:11 +, Gerd Petermann wrote:
> Hi Ticker,
>
> I think I understand the changes in the points file and in
> inc/accesss_country and they look okay to me. I agree that it is
> better to have the hotel POI
> for those cases
Hi
Some comments on "Some changes to be considered?"
On Sun, 2019-01-13 at 11:11 +, Joris Bo wrote:
> Hello,
...
> Some changes to be considered?
> ===
> Different kinds of public transport are mapped to the same symbol.
> For now I choose
Hi
Here is a patch to change some TYPE element numbers in default/lines:
Changes are:
Use 0x30 for leisure=track instead of treating it like a footpath.
0x30 was introduced in the last set of changes as the code for various
sports tracks (gallop, raceway)
Use 0x0b (Road) instead of 0x06 as the
Hi
Here is a patch to change some TYPE element numbers in default/points:
Changes are:
Always use 0x2f0c instead of 0x4e00 for amenity=toilet.
0x4e00 isn't findable. 0x2f0c is "Other:Rest Area/Tourist Info".
add:
tourism=resort [0x2b04 resolution 24]
This is searchable under the "Lodgings" >
Hi
Sorry about the delay in replying.
I couldn't decide on a good colour for Historic either, and, at the
moment, I use the same colour for Building, Historic and Amenity.
I think the default style should output them as polygons not POI. A typ
-file can consider not rendering these polygons.
Hi
Here is a patch to change some TYPE element numbers in
default/polygons:
Changes are:
0x17, which shows as "Park" in green, is currently used for these OSM
objects:
park, playground, common, garden, greenfield, meadow, grass,
village_green, square/plaza
Keep this mapping for leisure=park,
them. Most of those ways are mapped by HOT
> projects, it is very likely that they are not connected or self
> intersecting etc.
> I'd rather remove the mop up rule instead of adding a lot of "try to
> guess better" rules.
>
> Gerd
>
> _______
Hi
Once my current batch of changes is out of the way the next one will be
to change some if the element ids, mostly as per posting 13-Nov-18
17:25 UTC
I still think these typ files should go into trunk now and the default
-typ branch is abandoned
I don't like the name 'mkgmap.txt', not sure
Hi
I agree that bad tagging should be fixed in OSM but:
1/ some of the tags you mention here are acceptable
2/ it is a continuous job as some common mis-uses just get repeated
3/ its time-consuming
4/ it may be difficult for a non-local person to know exactly what the
highway really is
5/ my
Hi
In the latest release default style, all highway=* except pedestrian
that have area=yes or come from multi-polygon relations have id 0x05
(Parking lot)
In my latest batch of changes the polygon rule is:
(highway=services | highway=rest_area) & area!=no [0x05 resolution 22]
but, I agree, it
th and other typos during the
> last weeks.
>
> Gerd
>
> ________
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Dienstag, 4. Dezember 2018 17:50
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] default sty
it should be service. Can you give
> an example for a rest_area which should be routable?
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Mittwoch, 5. Dezember 2018 12:53
> An: Development list f
ed path.
> 2) rest_area is converted to a routable way?
>
> Gerd
>
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Montag, 3. Dezember 2018 16:04
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev]
Hi Gerd
Here is revision to defaultStyleTidy3.patch. The changes are:
1/ change highway=trail to highway=path; add bicycle=no instead of
track
2/ don't generate routable line for highway=rest_area
Regards
Ticker
Index: resources/styles/default/inc/access_country
I just generate an XML file with negative ids like:
...
and give as a parameter to splitter after the main osm.pbf map data
file.
Ticker
On Sun, 2018-12-02 at 16:02 +0100, Ben Konrath wrote:
> Hi Greg,
>
> On Tue, 27 Nov 2018 at 18:21, Greg Troxel wrote:
> > Semi-related, I
On my Etrex:
Map Setup > Advanced Map Setup >
Zoom Levels >
Auto zoom: on/off
Zoom Levels >
4 controls for the resolutions at which following appear
Points/Waypoints/Street labels/Land Cover
Text Size (Points, Streets, Etc) >
4 controls for Points/Waypoints/Street
Hi
Here is the third batch of default style changes. Changes are:
Add GBR section to inc/access_country and tidy up the layout
LINES
A few minor layout tidy-ups
Do aeroway=runway/taxiway/taxilane as lines unless marked as area=yes
and show these lines even when also a highway
Ignore more
Hi
Much simpler, clearer and more efficient, just:
whitewater='put_in;egress' [0x6516 resolution 24]
Ticker
On Wed, 2018-11-28 at 15:24 -0600, ValentinAK wrote:
> Hi Gerd.
> Thanks for the answer!
> I solved this task in the following way:
>
> whitewater ~ 'put_in\p{Punct}egress' [0x6516
Yes - I saw the nodes marked "part of way ..." and just presumed they
were the road; sorry for wasting your time.
Ticker
On Wed, 2018-12-05 at 17:06 +, Gerd Petermann wrote:
> Hi Ticker,
>
> the first example shows why it is not a good idea to make it
> routable. It is not connected to the
Hi
I like the solution to have the same behaviour as a polygon that comes
from a closed way: the joined way is passed to a concatenation of the
lines and polygons rules. It has the tags of the relation and
mkgmap:mp_created=true but mkgmap:stylefilter=poly{line/gon} is not
added.
The option that
Hi Andrzej
Is this logic general enough to move into the default style?
I assume it replaces:
# Display highway shield for mayor roads if they have a ref and make
them searchable by their name
(highway=motorway | highway=trunk) & ref=* {name '${ref|highway
-symbol:hbox}'; addlabel '${name}'}
Hi Gerd
Should we start dist/examples/TYPs/* as per my email on 19-Nov?
Ticker
On Mon, 2018-11-19 at 12:44 -0500, Greg Troxel wrote:
> Ticker Berkin writes:
>
> > I suspect there will be a few TYP files for different usages.
>
> perhaps, but as I understand it
Hi Gerd
Given lack of objections to any of this, could defaultStyleTidy2.patch
be applied to trunk.
Thanks
Ticker
On Fri, 2018-11-16 at 16:56 +, Ticker Berkin wrote:
> Hi
>
> This is the next batch of default style changes.
>
> I don't think anything here is contenti
ld be rendered and how?"
> Do you think we need another branch or do you think that the exising
> one makes no sense?
>
> Gerd
>
> ____
> Von: Ticker Berkin
> Gesendet: Dienstag, 27. November 2018 11:37
> An: Gerd Petermann; Devel
Hi Gerd
I'd hoped and expected that all polygons were fed into the 'lines'
style processing in a similar manner, regardless of their origin as
either a closed OSM way or generated by multiPolygonRelation. This
would allow simple testing using just 'is_closed()=true' to effect
lines around
you have to do in the relations style
> file.
>
> Gerd
>
> ________
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Donnerstag, 22. November 2018 17:03
> An: mkgmap development
> Betreff: [mkgmap-dev] closed ways and multi-polygon relations
>
> Hi Gerd
Hi
I suspect there will be a few TYP files for different usages.
I propose that they should be handled like the styles, where they are
gathered in a directory resources/TYPs and the build process copies
then to dist/examples/TYPs
I don't think a new branch is necessary, as there is nothing in
on't like the directory name TYPs. One reason is that the
> directory doesn't contain *.TYP files, the other is that one might
> want to write TYPes instead.
> I'd prefer typ-files or maybe typ-sources.
>
> Gerd
>
>
> Von: mkgmap-dev im Auftra
__
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Dienstag, 27. November 2018 09:56
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] New branch for default typ file
>
> Hi Gerd
>
> Happy with either, but slightly prefer typ-files.
&
Hi Gerd, Andrzej & maybe others
I'm trying to understand a couple of bits of logic in the default
style:
'relation' sets mkgmap:us_interstate, mkgmap:us_usroute and
mkgmap:us_state but I can't find any use of these tags. It looks like
these were introduced in revision 3979, 5-Aug-2017 following
Hi
This is the next batch of default style changes.
I don't think anything here is contention. The changes are:
A few minor white-space changes that I missed in the previous batch.
Remove unnecessary () in conditions
Add tmp: prefix to tags that are just used by the style logic, so it is
couple of thoughts
I've experienced the devices remembering parts of the map structure and
being in a bit of a mess when I've used the same map but copied to a
differently structured SD card. Maybe the newer firmware has a
different idea of the internal structures. So, suggest you make a new
map
Hi Gerd
Here a new version of the patch with this wording.
Ticker
On Wed, 2019-01-09 at 15:15 +, Gerd Petermann wrote:
> # squares and plazas
> place=square [0x17 resolution 22]
> highway=pedestrian & (area=yes | mkgmap:mp_created=true) [0x17
> resolution 22]
> # following rule also renders
rsion
> would be OK.
>
> Gerd
>
>
>
>
> ____
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Donnerstag, 10. Januar 2019 10:37
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] default style impr
Hi
On Sun, 2019-01-06 at 08:50 -0500, Greg Troxel wrote:
> Bernhard Hiller writes:
>
> > I often travel on bike in "nowhere land", where hotels and
> > restaurants
> > are rare. So I think it is good to show both PoIs if a hotel
> > contains
> > a restaurant. Of course, it would be more
s regardless if area=yes is set or not.
> So this is not a valid example, actually I can not find one really
> evident of missing area=yes on pedestrian areas.
>
>
> Lorenzo
>
>
>
>
> Il giorno dom, 06/01/2019 alle 17.37 +, Ticker Berkin ha scritto:
> >
: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Donnerstag, 3. Januar 2019 11:59
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] default style improvements
>
> Hi Gerd
>
> Do you want me to do another version of this patch before you commit
> it?
&
I agree with Gerd, the examples I've found of
shelter_type=public_transport are next to highway=bus_stop or similar
and are best ignored. It would be better if the stop was tagged with
shelter=yes or covered=yes, then the default style appends * or + to
the ref.
I have no problem with most
Hi Gerd
Here is summary of the changes:
A few minor layout tidy-ups
Add GBR section to inc/access_country
Do aeroway=runway/taxiway/taxilane as lines unless marked as area=yes
and show these lines even when also a highway
Ignore more highways when abandoned/disused/demolished
Ignore more
t like
> > # assume that a closed way with highway=pedestrian is meant to
> > describe an area even if area=yes is missing
> >
> > Gerd
> >
> > ________
> > Von: mkgmap-dev <
> > mkgmap-dev-boun...@lists.mkgmap
road_class=0 road_speed=2
> resolution 22]
> Line 201: highway=cycleway [0x07 road_class=0 road_speed=1
> resolution 23]
> Line 214: highway=turning_loop | highway=turning_circle |
> highway=layby | highway=escape | highway=emergency_bay [0x07
> road_class=0 road_
Hi
I seem to remember there was a suggestion a while ago (before may 2017)
to reorder the styles/default/polygons to move the include
'inc/*_polygons' up in the file to before "# building tag should be
last". I did this and had no problem with Lake Garda when I generated
italy-latest in July this
t; all-elements.
> I also never noticed that the map has no background polygon 0x4b. I
> think the proper way to handle this is to set
> the transparent flag in ElementTestDataSource.getPoiDispFlag().
> Do you agree?
>
> Gerd
>
> ____
>
Hi
I noticed a while ago that "test-map:all-elements" stopped working
correctly. The map it generated showed a box around the map area, but
within the map area, the device said 'no-map' and didn't show anything,
however POI searches did work.
I tracked it down to a couple of lines added to
I'm away from my development computer this weekend. I'll investigate on
Monday
Ticker
On Sat, 2019-04-06 at 08:16 +, Gerd Petermann wrote:
> Hi,
> maybe a regression from r4167?
> http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap=4167
>
> Gerd
>
>
Hi
0x1e04 is a strange choice for an house number point. 0x1e00 is "State"
and has a big font and might not support sub-types
Ticker
On Fri, 2019-03-29 at 13:32 +0100, DD8KQ wrote:
> Hi Gerd
>
> as you suggested, i added the continue statement to the directive,
> but,
> its still not working
Hi Gerd and Nick
@nick, when you say it works on 4143 but not on 4179, did you test code
-page=1255 on 4143, or just unicode?
It looks like there are 2 problems.
The --unicode assertion error is a 'byte' to 'int' sign-extension
problem, introduced in r4167 or r4168 and I've attached a patch
t --add-pois-to-lines is a rather problematic option,
> but I see no need to add no-add-pois-to-lines
> - My understanding is that we don't need order-by-decreasing-area
> once we have a default typ?
>
> Gerd
>
>
> ________
> Von: mkgmap
Hello Michael
Thank you for your work checking all of this and your feedback.
See embedded for my comments.
Kind regards
Ticker
On Sun, 2019-02-17 at 11:01 +0100, Michael Poesdorf wrote:
> Hello Ticker
>
> I had a look into the 3 mails/proposals of yours.
> Point and Lines are in a way easy.
it's the firmware, or maybe there is a bug. I guess you see
> this problem also with other (longer) street names?
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Mittwoch, 20. Februar 2019 11:38
>
Hi
Are you sure? I think this disagrees with my set-up, which works.
In a subdirectory for a particular country, I have script with like:
java -jar ../splitter/splitter.jar --geonames-file=../cities15000.zip -
-mapid=74320001 netherlands-latest.osm.pbf
Hi
I've never seen the value of mapset-name (default "OSM map set") appear
in any context on either of my devices, but I do see the value of -
-family-name on the eTrex Legend in one of the "Map Setup" sub-menus,
where there are options to Hide/Show Basemap and Hide/Show {family
-name} and this
Hi
I have a few suggestions / comments:
I don't agree with --recommended because this file will often required
some tweaking and eventually become the basis of the new users building
environment.
I think forward slash (/) works as a directory seperator on DOS/Windows
so can always use this.
It
ested r 4262 and it is working very well for me.
> Just adopted some resolutions of lines according to my personal
> flavour.
>
> Regards, Michael
>
> -Ursprüngliche Nachricht-
> Von: mkgmap-dev Im Auftrag
> von Gerd
> Petermann
> Gesendet: Dienstag,
, Gerd Petermann wrote:
> What you describe would be an error in my understanding. Can you
> still reproduce it?
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Dienstag, 19. Februar 2019 19:06
> An: D
m the small, presented list
of 5 in this case) and then be shown the matching addresses in just
this street.
Does this make sense?
Ticker
On Tue, 2019-02-19 at 17:26 +, Gerd Petermann wrote:
> Hi Ticker,
>
> I don't understand what you mean with
> "Removing all the common suff
Hi Gerd
Given the lack of comments and objections, can you apply my 3 patches
to default style points/lines/polygons from 21-Jan
Thanks
Ticker
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
Hi
I think it is reasonable that mkgmap, when explicitly being used to
generate GMAPSUPP.IMG doesn't generate PC files unless other options
imply that a PC image is also wanted - it does take extra time and a
lot of memory. Options --gmapi or --tdbfile imply PC files are wanted
and should cause
Hi Gerd
Attached is a patch that takes Steve's changes for Hebrew and a merges
his other changes with my patch from 8th Apr that removes a lot of
pointless swapping between byte/char and int and also fixes the sign
-extension problem.
Regards
Ticker
On Mon, 2019-04-08 at 21:22 +0100, Steve
Hi
Another problem discovered when investigating indexes.
If you have a map with cities but no streets, MDR5 sets the flag that
indicates MDR20 indexes are present, and writes an erroneous byte after
each record.
Attached patch fixes and adds some more flag documentation.
Regards
Ticker Index:
Hi
While trying to diagnose a indexing problem, I find that a bit code in
imgfmt/app/mdr/MdrUtils.java:getGroupForPoi() troublesome:
...
* 4-5 Recreation / Entertainment / Attractions
* 6 Shopping
* 7 Auto Services
* 8 Community
* 9 ?
*
Hi
I was wrong - MDR 9 & 10 are correct regardless of the out-of-order
0x28/group 9.
Sorry wasting your time.
Ticker
On Tue, 2019-04-16 at 11:50 +0100, Ticker Berkin wrote:
> Hi Gerd & Steve
>
> When I was running with a small example it seemed that the MDR9 was
> wr
Hi
1st - check if an earlier rule sets area=...
Your lines rule will give a line unless it has area=yes - the way being
closed has no effect.
Use is_closed() and/or mkgmap:mp_created to change the behaviour to
what you want
Ticker
On Sat, 2019-04-13 at 20:07 +0200, Manfred Haiduk wrote:
> Hi
Hi
I found that, without TYP definition, line 0x30 didn't show on eTrex
30x or eTrex Legend HCx. They were there; hovering the cursor in the
right place allowed them to be selected.
0x30 - 0x4f behaved like this
Ticker
On Sat, 2019-06-22 at 22:51 +0200, Manfred Haiduk wrote:
> Hi
>
> does
Hi Alexis
On Wed, 2019-07-10 at 16:58 +0200, Alexis Huxley wrote:
> Hi, I'm using mkgmap r4287 and trying to process continent files from
> geofabrik, e.g. http://download.geofabrik.de/asia-latest.osm.pbf.
>
> For about the last six months (today included) I have
>
Hi Alexis
On Thu, 2019-07-11 at 14:31 +0200, Alexis Huxley wrote:
> Thanks Ticker!
>
> > > The splitter output looks okay, though I note it ends:
> > >
> > > Number of MapFailedExceptions: 1
>
> > you should check out this error
>
> I reworked my wrapper script so splitter and mkgmap save
Hi
I think the mkgmap internal handling of types/subtypes of points is
obscure.
In the points style file, the type code is always full, ie type << 8 |
subtype, but when the points are read back from the RGN file for the
MDR processing, the representation is the same provided the subtype is
not
Hi Gerd & Steve
When I was running with a small example it seemed that the MDR9 was
written in group order, each with start record to MDR10 that is
calculated on the assumption that MDR10 was also generated in the same
group order. However the step in MDR10 caused by a single 0x28/group 9
POI
Hi
Not an answer to your question, but maybe relevant:
The default style has, in "options":
levels = 0:24, 1:22, 2:20, 3:18
My reading of the "Style Conversion Manual" says that elements with
a resolution between the levels are included in the higher res/lower
level map; ie. elements with
___
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Donnerstag, 1. August 2019 18:15
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] how to deal with "Attention: Tile contains
> both drive-on-left (303) and drive-on-right roa
> is ignored.
>
> I don't understand the last paragraph. I thought this is handled well
> in inc/access?
>
> Gerd
>
> ________
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Donnerstag, 1. August 2019 21:00
>
Hi Gerd
Another case where I get similar errors is when there is a barrier that
imposes a restriction that is on the join of 2 ways (quite a common and
sensible thing to do):
WARN: uk.me.parabola.mkgmap.osmstyle.StyledConverter 74210002.osm.pbf:
Access restriction in POI node
Hi
I've found that my eTrex 30x, asking for a shortest distance
car/motorcycle route, will use a road that has mkgmap:car=no as an
intermediate part of of the route rather than a much longer route using
just valid roads. I've only noticed this where the non-car road is very
near the start/end of
Hi Gerd
I've just updated my build from 4288 to 4293 and I'm now getting quite
a few of these errors
SEVERE (RoadDef): 74220089.osm.pbf: internal error? The nodeCount
doesn't match value calculated by RoadNetWork: (
http://www.openstreetmap.org/browse/way/26552046)
SEVERE (RoadDef):
Hi
It doesn't work like this. The OSM tags can express situations that are
much more complicated than can be represented in the GARMIN IMG format
and mkgmap processing transforms OSM tags into the the simpler GARMIN
data structures. A particular GARMIN device (or other software, eg
Basecamp) will
nodeCount
doesn't match value calculated by RoadNetWork: (
http://www.openstreetmap.org/browse/way/24556428)
Number of MapFailedExceptions: 0
Number of ExitExceptions: 0
Time finished: Sat Sep 28 07:03:44 BST 2019
Total time taken: 44 seconds
Ticker
On Fri, 2019-09-27 at 13:48 +0100, Ticker Berkin w
.
> I found no older versions of mkgmap where this would have worked
> different, so it seems useless to me because normally I'd want to be
> able to find the bus station under transport services.
>
> Why do you use 0x1101, 0x1102, or 0x1108 for POI?
>
> Gerd
>
> ___
Hi
I think the default should be either:
Don't check for routing islands
or:
Check for and remove islands of any length
but I don't feel that strongly about this aspect.
In the documentation, it should mention the effect of a road meeting a
tile boundary or boundary nodes added at admin
Hi Gerd
I get this with r4338:
java.lang.IndexOutOfBoundsException: Index: 0
at java.util.Collections$EmptyList.get(Collections.java:4454)
at
uk.me.parabola.imgfmt.app.net.NETFile.createSortKeysyNameAndCity(NETFil
e.java:166)
at
___
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Samstag, 2. November 2019 19:30
> An: mkgmap development
> Betreff: Re: [mkgmap-dev] [mkgmap-svn] Commit r4338: merge from trunk
> r4337
>
> Hi Gerd
>
> I get this with r4338:
Ticker
On Thu, 2019-11-07 at 11:56 +, Ticker Berkin wrote:
> Hi Gerd
>
> MdrDisplay/cityPtrSize:
>
> I didn't change any significant behaviour. Because it seemed
> inconsistent, I put in a diagnostic. I also made the switch stmt in
> printSec11_city like the similar i
_
> Von: mkgmap-dev im Auftrag
> von Gerd Petermann
> Gesendet: Donnerstag, 7. November 2019 13:18
> An: Ticker Berkin; mkgmap development
> Betreff: Re: [mkgmap-dev] type/subtype of points and cities
>
> Hi Ticker,
>
> the problems with All
java -jar mkgmap.jar --index --gmapi test-map:all-elements
> It crashes when you search for all POI and also when you search for
> cities (both without giving a name)
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
&g
Hi Gerd
I've tweaked the file a bit and put a hint to it in the README in the
root directory of the distribution; this file is very out-of-date but I
didn't want to start re-writing it.
Attached is the updated patch and resources/sample.cfg (which I
couldn't work out how to get into the patch
th the file.
> I think the README is not distributed, so you have to change
> build.xml as well.
>
> If you use svn patch with my patch the file is "automagically" svn
> -aded
>
> Gerd
>
> ________
> Von: mkgmap-dev im Auftra
the changes.
>
> Gerd
>
>
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Montag, 15. April 2019 17:49
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Building map with Hebrew characters
>
Hi Gerd
It would be good if this idea was resurrected - initially just
releasing the file, as you last had it, somewhere under
trunk/resources. Then suggestions can be incorporated and mention made
of it elsewhere in the documentation.
Ticker
On Thu, 2019-02-21 at 10:50 +, Ticker Berkin
es in my style
> -file. The unconnected_type is now obsolete if you just used to
> disable routing by setting an unroutable type - correct?
>
> Have you tested that the global option is run after
> semi_connected_type and unconnected_type? Because first the style
> should be able
yes, sorry. my email spell checker is set to american and I wasn't
thinking.
Ticker
On Tue, 2019-11-05 at 11:40 +0100, Colin Smale wrote:
> On 2019-11-05 11:12, Ticker Berkin wrote:
> > Also fix "metres" to "meters"
> >
> Metres is the co
__
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Montag, 4. November 2019 18:12
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] type/subtype of points and cities
>
> Hi Gerd
>
> To stay compatible with "Openfietsmap full"
er 2 or 3, so maybe
> perform the test once in printHeader() using the logger instead of
> System.out.printf()?
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Dienstag, 5. November 2019 12:44
> An: mk
:15 +, Ticker Berkin wrote:
> Hi Gerd
>
> Yes, I'll change allElements to not try subtypes for isCityType, and,
> elsewhere, assert that indPoints don't have a subtype.
>
> My Etrex only shows points in the range you mention in the results
> for
> nearby cities,
t;
>
>
> Von: mkgmap-dev im Auftrag
> von Gerd Petermann
> Gesendet: Freitag, 22. November 2019 12:57
> An: Ticker Berkin; Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Basecamp and NET/NOD changes
>
> Hi Ticker,
&
Hi Gerd
Thanks for investigating this. As the eTrex routing seems to work
(maybe it is more similar to Mapsource than Basecamp) I'll persist with
island removal.
Looking at display:NetCheck errors, it looks like the RoadDef.netFlags
bit:
RoadDef: public static final int NET_FLAG_ADDRINFO =
style file containing something like
>
> # routing island replacement types
> 0x01: 0x10800
> 0x02: 0x10801
> 0x03: 0x10802
>
> 0x07: none
> ...
>
> Gerd
>
> ____
> Von: mkgmap-dev im Auftrag
> von Gerd Petermann
&g
s
> > wrong. It renders as a gray area and may hide the sea below.
> > I am not sure what the correction is. If possible I would use
> > "transparent" without any colour, else the same as 0x32.
> >
> > Gerd
> >
> >
Hi
Sorry - seems that the name went from mkgmap.txt
Ticker
On Mon, 2019-12-09 at 15:13 +, Ticker Berkin wrote:
> Hi
>
> My understanding was that mkgmap.txt rather than mapnik.txt was going
> to be one of the typ-files examples
>
> Ticker
>
> On Mon, 2019-12-09
Hi Joris & Gerd
Great to see the typ-files now in trunk and all the work in updating
mapnik.txt to the current default style. Next week I plan to go through
"20191209 mapnik update.pdf" and comment on it and possible changes to
the default style.
Some other questions however:
How do you see
201 - 300 of 1100 matches
Mail list logo
