which is work in progress. I did not yet make up
> my mind regarding lambdas. They are nice to simplify code but
> sometimes it is much harder to debug them in Eclipse.
>
> ________
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Die
onal ~
> '!(sunset|sunrise|destination)' { name
> 'bicycle=${bicycle:conditional}' } [0x1108 resolution 24]
> vehicle:conditional=* & vehicle:conditional ~
> '!(sunset|sunrise|destination)' { name
> 'vehicle=${vehicle:conditional}' } [0x1108 resolution 24]
>
> Can you explain what happen
Hi Gerd
Here is the patch based on the current trunk
Ticker
On Tue, 2019-04-23 at 11:51 +0100, Ticker Berkin wrote:
> 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
Hi Gerd
I noticed this problem in April and there was a fix to it in the patch
that simplified/clarified point type/subtype and city range handling:
http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2019q2/029623.html
The posting didn't elicit any responses, but I think the changes
worthwhile. If you
ay/153273366 is empty.
> Do you think that mkgmap should start guessing what the role of the
> way is? In this case that would be possible, but I'd still prefer
> that someone fixes the data in OSM.
>
> Gerd
>
>
> Von: mkgmap-dev im Auf
Hi Gerd
Just doing more experimenting with mkgmap-NET-no-NOD-r4304 and options:
--no-route --net
I get lots and lots of messages like:
WARN: uk.me.parabola.mkgmap.reader.osm.ElementSaver 74210002.osm.pbf:
ignoring unspecified/unsupported restriction
t; http://www.openstreetmap.org/browse/way/511855021) is removed from
> NOD, length: 22 m
> SEVERE (RoadDef): e:\osm_out_work\wales\63240001.osm.pbf: road (
> http://www.openstreetmap.org/browse/way/511855021) is removed from
> NOD, length: 3 m
> ...
> It shows that many islands are in
Hi Gerd
I don't understand what is meant by 'Street Search'. Is this just the
use of 'Address Search' where the House Number field is cleared?
Otherwise looks OK to me.
Ticker
On Sun, 2019-10-20 at 06:40 +, Gerd Petermann wrote:
> Hi all,
>
> the current code implies --net if option
higher counts as each end of an unconnected way is
> also a routing node.
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Freitag, 18. Oktober 2019 16:28
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Please
thanks for testing. I'll work on a patch without recursive calls.
>
> Gerd
>
> ________
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Freitag, 18. Oktober 2019 12:41
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] P
se
> play with it and let me know how it works for you.
>
> Gerd
>
> ________
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Samstag, 12. Oktober 2019 19:34
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Please test branch NET-no-NOD
>
ces but sometimes there car-park was defined by more than 1
line.
Ticker
On Sat, 2019-10-12 at 10:10 -0700, Gerd Petermann wrote:
> Ticker Berkin wrote
> > Do you attempt to isolate small road networks that are not
> > connected to
> > the rest of the system or just a single road?
&g
r
On Sat, 2019-10-12 at 15:33 +, Gerd Petermann wrote:
> Hi Ticker,
>
> I just committed r4302, please try with that.
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Samstag, 12. Oktober 2019 17
Hi Gerd
I'm just starting to test this, but looking through the log lines (I
get 1260 of them for 2 tiles) like:
SEVE: uk.me.parabola.mkgmap.osmstyle.StyledConverter 74210001.osm.pbf:
check: road without connection is not written to NOD Newport to Cowes
cycleway (OSM id 562475661)
Hi Gerd
Is there a build available for this that I can download, rather than
creating a branch.
Thanks
Ticker
On Sat, 2019-10-12 at 10:17 +, Gerd Petermann wrote:
> Hi all,
>
> I've tried to work out under what conditions we need routing nodes
> when using OSM input (not polish *mp):
>
Hi Gerd
(I started writing this before your next post arrived)
Assuming I understand the resultant behaviour correctly concerning the
2nd change: I'm against the idea not having NODs for terminal roads
becoming the default. It may not have obvious effects in heavily built
up areas, but
n, the
> calling code seems to make sure that via ways are not split.
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Gerd Petermann
> Gesendet: Freitag, 11. Oktober 2019 06:53
> An: mkgmap-dev@lists.mkgmap.org.uk
> Betreff: Re: [mkgmap-dev] [Patch] improve ha
__
> Von: mkgmap-dev im Auftrag von
> Ticker Berkin
> Gesendet: Donnerstag, 10. Oktober 2019 20:51
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] [Patch] improve handling of only-restrictions with
> via ways
>
> Hi Gerd
=crossing {set mkgmap:road-speed=1}
I expect this explains most of the "can't locate arc" errors.
Don't worry about any of this on my behalf - I suspect this could be
complicated to solve.
Ticker
On Thu, 2019-10-10 at 19:23 +0100, Ticker Berkin wrote:
> Hi Gerd
>
> So
tion is
> not completely within the bounds of that tile.
>
> Gerd
>
> ________
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Donnerstag, 10. Oktober 2019 18:14
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] [Patch] improve handli
Hi Gerd
No problems that I can see - but very difficult to test.
I've run 'british-isles-latest' with the patch.
There is 1 extra error message that a duplicate, ie I get:
SEVERE (RoadNetwork): 74220083.osm.pbf: Turn restriction
(only_straight_on) http://www.openstreetmap.org/relation/8727983
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
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
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
I agree that this rule is wrong and to express it correctly is
complicated, needing expansion of the composite transport modes
(vehicle, motor_vehicle, psv) and then testing of all the routable
modes (foot, bicycle, motorcar etc) to see if the global access= is
relevant.
There are only a
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
> 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
>
___
> 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
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 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 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
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
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
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 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
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 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
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 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
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
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
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
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
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
>
, 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
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.
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,
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
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
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/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,
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.
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 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
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 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
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
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:
> >
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
> >
> 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
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
lle 17.18 +0000, Ticker Berkin ha scritto:
> >
> >
> > highway=pedestrian always generates a line and, unless area=no, a
> > polygon. This is the OSM representation of a square/plaza, and, in
> > many
> > cases, needs the routing given by the edge. The ar
ehind e.g. tourism=hotel?
> I think you often find OSM objects tagged with both
> amenity=restaurant and tourism=hotel,
> and I'd prefer to find both. Probably a case for continue ?
>
> Gerd
>
> ________
> Von: mkgmap-dev im Auftrag
: 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?
&
Hi Gerd
Do you want me to do another version of this patch before you commit
it?
I'd like to get on with the next set of changes; minor things like
removing horse= can be done with these.
Regards
Ticker
On Thu, 2018-12-13 at 10:54 +, Ticker Berkin wrote:
> Hi Gerd
>
> My
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
Try removing the quotes from the option when it is the template file,
ie:
someOpt=value
name-tag-list=name:de,name
anotherOpt=value
Ticker
On Thu, 2018-12-27 at 21:22 +0100, Ralf Kleineisel wrote:
> Does using the mkgmap option "name-tag-list" break the address
> search?
>
> If I use
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 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
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
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
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
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
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
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
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
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
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
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
__
> 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.
&
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
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
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
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 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
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, 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
801 - 900 of 1100 matches
Mail list logo
