Re: [mkgmap-dev] unpaved roads

[Gerd Petermann]

Hi all,

I tried to create a patch for the rules which set mkgmap:unpaved using the wiki 
and taginfo:
https://taginfo.openstreetmap.org/keys/surface#values

One probem with surface is that we have so many values (taginfo lists 4844 
different today),
many of them typos or combinations like "ground;grass" or nonsense like 
"paved;unpaved"
I guess many of the latter were produced by "connect ways" functions in OSM 
editors, so not fully intended.

Anyhow, my impression is that it would be better to change the rule so that it 
checks the known
paved surfaces and assumes that all others mean unpaved.
The current rules are quite old, it was introduced with r1425 and last changed 
with r1489.

Comments?
Gerd

Von: mkgmap-dev  im Auftrag von Carlos 
Dávila 
Gesendet: Dienstag, 7. Februar 2017 12:39:49
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] unpaved roads

I don't agree with you. I think default style is a generic style, and as
such, it shouldn't do much guess but use the strict meaning of tags.
Gravel, fine_gravel, ice, etc. are strictly unpaved and I would mark
them as such in default style. More specific uses (mtb/race
bicycle/4wd...) require specific maps and thus specific styles.
@Mark: I'm also cyclist and for mtb use your "raining" point of view of
paved/unpaved is important to be considered.

El 07/02/17 a las 11:57, Nuno Pedrosa escribió:
> Hi! In Portugal, Spain and surely a little all around, unpaved gravel
> roads are common, even on urban neighbourhoods.
> These are quite drivable and they will often be the only way to get to
> some places. They are also suitable to all vehicles, even if they will
> get covered in dirt.
> There are also a lot of paths going through sand (forest roads) and
> these will unsuitable to most vehicles (even a lot of 4x4s),
> regardless of their width.
>
> I find that while driving, the real issue will be the road conditions
> and width. Will the unpaved road be wide enough for a car or light
> truck? Will it have deep tracks due to soil erosion? Will the surface
> be solid enough to drive in a regular car?
>
> So, in real world GPS usage, I would like unpaved to mean “narrow,
> earth roads”, while paved would mean any road suitable to all regular
> vehicles.
> Example: due to wind farms being built in a lot of hill ranges, large,
> unpaved roads were built. These are gravel, wide roads, and often are
> a better option to the paved, sinuous mountain roads that go around
> every nook and cranny in the valleys.
>
> So, I think that fine_gravel, salt and ice should still be “paved”.
>
> Nuno Pedrosa.
>
> PS: Sorry to “butt in” the talk. I’m usually silent in this list,
> though I read most of the discussions. Your work is amazing and I find
> that I can add little to what is being discussed, so I try to keep my
> “noise” to a minimum!
>
>
>> On 7 Feb 2017, at 09:40, lig fietser > > wrote:
>>
>> I'd call that semi-paved but Garmin doesn't have such category
>> unfortunately. Since the default style main focus is on motor
>> vehicles I'd suggest to add surfaces like fine_gravel, salt, ice to
>> the unpaved list. And please add soil to it, it seems a quite popular
>> tag.
>>
>> 
>> Gerd wrote
>> This "raining" part is probably what paved/unpaved is about: The
>> surface of a paved road should not change when it's raining
>> and your vehicle will not be covered with dirt when traveling on a
>> paved road while it is raining (at least not from dirt which was part
>> of the surface).
>>
>> Do you agree on that (last sentence)?
>>
>> Gerd

___
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] r3784 produces large img files than r3773

[Gerd Petermann]

Hi Ticker,

I may be wrong but I think that WanMil (the initial author) also tried 
something like that.
My understanding is that a shape with a very high aspect ratio is likely to 
"disappear" in the
RoundCoordFilter, giving white stripes or triangles in the sea.

Gerd

Von: mkgmap-dev  im Auftrag von Ticker 
Berkin 
Gesendet: Mittwoch, 8. Februar 2017 00:34:01
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] r3784 produces large img files than r3773

Hi Gerd

Yes - only horizontal lines (or all could be flipped to vertical).
Maybe quite long, but each the shortest distance from top of inner to
edge of outer (or earlier inner, which has now become part of the
outer). Not sure why this would be bad for further processing.

I was aiming for simplicity and efficiency. It was just a thought -
please ignore.

Ticker

On Tue, 2017-02-07 at 18:17 +, Gerd Petermann wrote:
> Hi Ticker,
>
> sounds to me as if this would produce only horizontal cut lines,
> possibly quite long and maybe
> very close to each other. That would be correct but not good for
> further processing.
>
> Gerd
> 
> Von: mkgmap-dev  im Auftrag
> von Ticker Berkin 
> Gesendet: Dienstag, 7. Februar 2017 18:43:43
> An: mkgmap-dev@lists.mkgmap.org.uk
> Betreff: Re: [mkgmap-dev] r3784 produces large img files than r3773
>
> Hi Gerd
>
> Algo:
>
> Assumes list of outer polygons and list of inner ones;
> Which inners go in each outer unknown.
> No additional layers of nesting.
>
> Best not to clipToBounds at start - complicates logic a lot.
> Also assumed that this hasn't happened from map generation/splitting
> -
> ie don't expect edge of inner to run along edge out outer.
>
> Sort inners into order of top most point. Note this point
>(if more than 1 equal top point, remember L outermost)
> For each inner:
>   For each outer:
> Make a test cut of outer across the line of inner top
> If resulted in >1 piece
>   look through lower pieces for segment that follows cut line and
>encompasses the top of the inner
>   if found
> note l distances from inner to ends of cut segment
> choose shorter and note end coord=x and 1 away from the cut=y
> go back to orig outer, find coord y
> depending on the outer direction and side make y prev coord
> // Now can insert the cut and inner after y:
> unclose inner
> reverse if same area/sign as outer
> rotate so that start is at top (l/r if appropriate)
> add these coords to orig outer after coord y:
>x, all inner, inner first coord, x
> break
>   end for each outer
>   error - didn't find outer for inner
> end for each inner
>
> That's it. Slight adjustments need to be made if x happens to be an
> original coordinate rather than one invented by ShapeSplitter
>
> Ticker
>
>
> On Tue, 2017-02-07 at 16:44 +, Gerd Petermann wrote:
> > Hi Ticker,
> >
> > I'd prefer to get a patch for MultipolygonCutter ;-)
> > I guess the problems are similar to those in the split algo.
> > Pseudo-Code for an alternative solution is also welcomed.
> >
> > FYI: I am implementing an index that allows to quickly find nearby
> > way segments , I will use that to find intersections in mp-rels
> > in the same way as I've implemented it with some patches for JOSM.
> > The index might be useful for my cut algo as well.
> >
> > Gerd
> > 
> > Von: mkgmap-dev  im Auftrag
> > von Ticker Berkin 
> > Gesendet: Dienstag, 7. Februar 2017 14:34:36
> > An: mkgmap-dev@lists.mkgmap.org.uk
> > Betreff: Re: [mkgmap-dev] r3784 produces large img files than r3773
> >
> > Hi Gerd
> >
> > orderByDecreasingArea only has a param declaration and single use
> > in
> > MapSplitter and its value transforms to
> > MapArea.splitPolygonsIntoArea
> > so I think it is better as it is.
> >
> > I had some thoughts on a simple/efficient algo for
> > MultiPolygonRelation
> > hole cutting - It won't produce the optimized cuts that yours is
> > aiming
> > for. If you are interested, I'll formulate some pseudo-code.
> >
> > Merge the branch whenever is best for you.
> >
> > Ticker
> >
> > On Tue, 2017-02-07 at 13:12 +, Gerd Petermann wrote:
> > > Hi Ticker,
> > >
> > > thanks, I am still working a new algos to replace parts of the
> > > existing code in MultipolygonRelation,
> > > esp. that for createContainsMatrix(). I hope to finish the first
> > > patch tomorrow.
> > > If that takes much longer I plan to merge the branch into trunk
> > > first.
> > > Reg. refactoring: What do you think about adding
> > > orderByDecreasingArea as a (final) field in MapSplitter?
> > >
> > > Gerd
> > >
> > >
> > > 

Re: [mkgmap-dev] is_in filter

[nwillink]

r Carlos

In my case with Oregons and GPS64  I also rename the gmapsupp.img to defined
the main label.



--
View this message in context: 
http://gis.19327.n8.nabble.com/is-in-filter-tp5890564p5890836.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

Re: [mkgmap-dev] r3784 produces large img files than r3773

[Ticker Berkin]

Hi Gerd

Yes - only horizontal lines (or all could be flipped to vertical).
Maybe quite long, but each the shortest distance from top of inner to
edge of outer (or earlier inner, which has now become part of the
outer). Not sure why this would be bad for further processing.

I was aiming for simplicity and efficiency. It was just a thought -
please ignore. 

Ticker

On Tue, 2017-02-07 at 18:17 +, Gerd Petermann wrote:
> Hi Ticker,
> 
> sounds to me as if this would produce only horizontal cut lines,
> possibly quite long and maybe
> very close to each other. That would be correct but not good for
> further processing.
> 
> Gerd
> 
> Von: mkgmap-dev  im Auftrag
> von Ticker Berkin 
> Gesendet: Dienstag, 7. Februar 2017 18:43:43
> An: mkgmap-dev@lists.mkgmap.org.uk
> Betreff: Re: [mkgmap-dev] r3784 produces large img files than r3773
> 
> Hi Gerd
> 
> Algo:
> 
> Assumes list of outer polygons and list of inner ones;
> Which inners go in each outer unknown.
> No additional layers of nesting.
> 
> Best not to clipToBounds at start - complicates logic a lot.
> Also assumed that this hasn't happened from map generation/splitting 
> -
> ie don't expect edge of inner to run along edge out outer.
> 
> Sort inners into order of top most point. Note this point
>(if more than 1 equal top point, remember L outermost)
> For each inner:
>   For each outer:
> Make a test cut of outer across the line of inner top
> If resulted in >1 piece
>   look through lower pieces for segment that follows cut line and
>encompasses the top of the inner
>   if found
> note l distances from inner to ends of cut segment
> choose shorter and note end coord=x and 1 away from the cut=y
> go back to orig outer, find coord y
> depending on the outer direction and side make y prev coord
> // Now can insert the cut and inner after y:
> unclose inner
> reverse if same area/sign as outer
> rotate so that start is at top (l/r if appropriate)
> add these coords to orig outer after coord y:
>x, all inner, inner first coord, x
> break
>   end for each outer
>   error - didn't find outer for inner
> end for each inner
> 
> That's it. Slight adjustments need to be made if x happens to be an
> original coordinate rather than one invented by ShapeSplitter
> 
> Ticker
> 
> 
> On Tue, 2017-02-07 at 16:44 +, Gerd Petermann wrote:
> > Hi Ticker,
> > 
> > I'd prefer to get a patch for MultipolygonCutter ;-)
> > I guess the problems are similar to those in the split algo.
> > Pseudo-Code for an alternative solution is also welcomed.
> > 
> > FYI: I am implementing an index that allows to quickly find nearby
> > way segments , I will use that to find intersections in mp-rels
> > in the same way as I've implemented it with some patches for JOSM.
> > The index might be useful for my cut algo as well.
> > 
> > Gerd
> > 
> > Von: mkgmap-dev  im Auftrag
> > von Ticker Berkin 
> > Gesendet: Dienstag, 7. Februar 2017 14:34:36
> > An: mkgmap-dev@lists.mkgmap.org.uk
> > Betreff: Re: [mkgmap-dev] r3784 produces large img files than r3773
> > 
> > Hi Gerd
> > 
> > orderByDecreasingArea only has a param declaration and single use
> > in
> > MapSplitter and its value transforms to
> > MapArea.splitPolygonsIntoArea
> > so I think it is better as it is.
> > 
> > I had some thoughts on a simple/efficient algo for
> > MultiPolygonRelation
> > hole cutting - It won't produce the optimized cuts that yours is
> > aiming
> > for. If you are interested, I'll formulate some pseudo-code.
> > 
> > Merge the branch whenever is best for you.
> > 
> > Ticker
> > 
> > On Tue, 2017-02-07 at 13:12 +, Gerd Petermann wrote:
> > > Hi Ticker,
> > > 
> > > thanks, I am still working a new algos to replace parts of the
> > > existing code in MultipolygonRelation,
> > > esp. that for createContainsMatrix(). I hope to finish the first
> > > patch tomorrow.
> > > If that takes much longer I plan to merge the branch into trunk
> > > first.
> > > Reg. refactoring: What do you think about adding
> > > orderByDecreasingArea as a (final) field in MapSplitter?
> > > 
> > > Gerd
> > > 
> > > 
> > > 
> > > Von: mkgmap-dev  im
> > > Auftrag
> > > von Ticker Berkin 
> > > Gesendet: Dienstag, 7. Februar 2017 13:45:25
> > > An: mkgmap-dev@lists.mkgmap.org.uk
> > > Betreff: Re: [mkgmap-dev] r3784 produces large img files than
> > > r3773
> > > 
> > > Done
> > > 
> > > On Tue, 2017-02-07 at 12:17 +, Gerd Petermann wrote:
> > > > Hi Ticker,
> > > > 
> > > > that's what I expected. Most shapes do not have too many 
> > > >  points
> > > > after line simplification.
> > > > 

Re: [mkgmap-dev] To do: If-Then-Else

[Dave Swarthout]

if () {
 some rules
} else {
other rules
}

That's exactly what I had in mind. Adding another parameter, like a
CONSTANT, to the invocation would work (especially for the case of building
clutter) but is not nearly as flexible or powerful as an internal
if-then-else capability to process style rules and act on them
conditionally.


On Wed, Feb 8, 2017 at 4:35 AM, Andrzej Popowski 
wrote:

> Hi Gerd,
>
> could you implement simple conditional statements, which would be analyzed
> at the stage of reading style? Similarly like statement "include" is
> processed.
>
> I think the simplest version would contain 3 tokens:
> ifdefined CONSTANT
> ifnotdefined CONSTANT
> endif
>
> Scanner should look for ifdefined/ifnotdefined, check if CONSTANT exist
> and then analyze or skip rules until it finds token endif. It should
> support nesting. CONSTANT would be given as command line option. Or maybe
> even as an additional token, like "define CONSTANT".
>
>
> --
> Best regards,
> Andrzej
>
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>



-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Problems with -- gmapi (and possibly --gmapsupp also)

[Patrik Brunner]

Steve,

Folder structure looks the same as with for example jmc_cli.

It doesn't make a difference if I call mkgmap --gmapsupp with the 
overview parameters (--overview-mapname=... --overview-mapnumber=...), 
in no case I have overview maps.
The only difference is how the files are named inside the gmap directory 
structure, either with the choosen names or with the default names.


Below shown call of mkgmap is the version without overview options...

Cheers
Patrik

On 06.02.2017 23:33, Steve Ratcliffe wrote:

Hi Patrik


I've just noticed that the quite new option --gmapi does not work
properly regarding overview maps:
- I first build the img files where all is correct, overview maps are
properly built and set at the different needed locations (*.tdb file,
elsewhere ?)
- running mkgmap with the option --gmapi (complete output shown below)
causes that the overview maps are not anymore shown in BaseCamp


How does the gmapi map differ from one created using the script or 
Garmin's conversion tool?




BTW: Something similar happens probably with --gmapsupp: there are now
overview maps visible on the GPS itself.


The gmapsupp does not contain a base map.  I suppose if you actually 
included it on the command line then it would be added, but you should

not do that.

..Steve

Here the call of mkgmap and its output:

java -Xmx1536M -Dfile.encoding=UTF-8 -jar 
D:/fzk/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/tools/mkgmap/mkgmap.jar 
--max-jobs=2 --index --code-page=1252 --gmapi 
--license-file=Freizeitkarte_LUX.license --product-id=1 
--family-id=6442 --family-name="Freizeitkarte_LUX" 
--series-name="Freizeitkarte_LUX" --description="Freizeitkarte_LUX 
(Release 17.02)" --product-version="6442" 6442*.img 6442.TYP 
--tdbfile --show-profiles=1

Time started: Sun Feb 05 16:10:10 CET 2017
Number of MapFailedExceptions: 0
Number of ExitExceptions: 0
Time finished: Sun Feb 05 16:10:12 CET 2017
Total time taken: 1858ms

Am I doing something wrong or is this a 'defect' in the newly
implemented gmapi option ?

Thanks for helping
Patrik


___
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] Problems with -- gmapi (and possibly --gmapsupp also)

[Patrik Brunner]

Gerd,

Sorry for the delay.

I've also tried it with --tdbfile and it didn't help.

I can post the 1st command probably tomorrow. I can just state the 
following about the outcome of the 1st command:

- the option --tdbfile is used and proper overview name and map are set too
- the outcome of the 1st command definitely contains the overviewmap 
properly, if I install the result from the first command into BaseCamp 
via registry I see the overviewmap.


Cheers Patrik


On 06.02.2017 09:28, Gerd Petermann wrote:

Hi Patrik,

I did not yet try to reproduce the problem. What jumps into my mind first is 
that the previously computed overview map is not found with
the argument 6442*.img. Or maybe you have to specify option --tdbfile to get an 
overview map.

If that doesn't help please post also the 1st command.

Gerd

Von: mkgmap-dev  im Auftrag von Patrik 
Brunner 
Gesendet: Sonntag, 5. Februar 2017 16:20:08
An: Development list for mkgmap
Betreff: [mkgmap-dev] Problems with -- gmapi (and possibly --gmapsupp also)

Gents,

I've just noticed that the quite new option --gmapi does not work properly 
regarding overview maps:
- I first build the img files where all is correct, overview maps are properly 
built and set at the different needed locations (*.tdb file, elsewhere ?)
- running mkgmap with the option --gmapi (complete output shown below) causes 
that the overview maps are not anymore shown in BaseCamp

I've tried different versions of options but I do not get the overview maps 
working with --gmapi.

BTW: Something similar happens probably with --gmapsupp: there are now overview 
maps visible on the GPS itself.

Here the call of mkgmap and its output:

java -Xmx1536M -Dfile.encoding=UTF-8 -jar 
D:/fzk/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/tools/mkgmap/mkgmap.jar  --max-jobs=2 --index --code-page=1252 
--gmapi --license-file=Freizeitkarte_LUX.license --product-id=1 --family-id=6442 
--family-name="Freizeitkarte_LUX" --series-name="Freizeitkarte_LUX" 
--description="Freizeitkarte_LUX (Release 17.02)" --product-version="6442" 6442*.img 6442.TYP 
--tdbfile --show-profiles=1
Time started: Sun Feb 05 16:10:10 CET 2017
Number of MapFailedExceptions: 0
Number of ExitExceptions: 0
Time finished: Sun Feb 05 16:10:12 CET 2017
Total time taken: 1858ms

Am I doing something wrong or is this a 'defect' in the newly implemented gmapi 
option ?

Thanks for helping
Patrik
___
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] Merging layers in a map (was is_in filter)

[Carlos Dávila]

El 07/02/17 a las 22:06, nwillink escribió:

For years now I have been keeping all buildings as a separate transparent
gmapsup /img  giving it a higher priority/draworder then my normal maps - It
has speeded up my daily runs without loss of detail - same could be done for
rivers/streams etc.
As a bonus I can ,if I wanted to, switch off/on buildings on my device, bit
like contours.
I update my buildings.img when necessary.

This is not an answer to the initial problem but it works

r

Nick

Thanks Nick for the hint.
I had already tried this approach to separate my topo map into three 
layers: base map, topo specific elements and contour lines but I get 
very different behavior on different Garmin models. Up to now I have 
done only a simple test with the commands and results shown below:

#Base map:
java -Xmx600m -ea -jar mkgmap.jar --bounds=bounds.zip --route --latin1 
--code-page=1252 --country-name=ESPAÑA --country-abbr=ESP 
--family-name="OpenStreetMap Extremadura" --family-id=113 --product-id=1 
--description="OpenStreetMap-Extremadura" 
--series-name="OSM-Extremadura"  --area-name=España 
--overview-mapname=ESP-113 --mapname=55113001 --index 
--process-destination --process-exits --housenumbers --add-pois-to-areas 
--adjust-turn-headings --report-similar-arcs --link-pois-to-ways 
--location-autofill=is_in --drive-on=right 
--style-file=../resources/styles --style=base typ/ESP-113.TYP 
extremadura.o5m


#Topo layer
java -Xmx600m -ea -jar mkgmap.jar --family-id=513 --product-id=1 
--family-name="Topo Extremadura" --series-name="Topo-Extremadura" 
--area-name=España --overview-mapname=ESP-513 
--overview-mapnumber=55513000 --transparent --draw-priority=26 --latin1 
--code-page=1252 --style-file=../resources/styles --style=topo 
extremadura.o5m


#Merge all layers (contours are prebuilt transparent 60213*.img files 
with draw-priority=28)
java  -ea -jar mkgmap.jar --latin1 --code-page=1252 
--description="OSM+Topo-Extremadura" --country-name=ESPAÑA 
--country-abbr=ESP --family-name="OSM+Topo Extremadura" --family-id=313 
--product-id=1 --series-name="OSM+Topo Extremadura" --area-name="España" 
--overview-mapname=ESP-313 --overview-mapnumber=65313000 --index 
--show-profiles=1 ../mapas/extremadura/55113*.img 
../mapas/extremadura/6324*.img ../mapas/extremadura/60213*.img 
../mapas/extremadura/ESP-313.TYP


Legend HCx: each single tile must be enabled/disabled separately. Tiles 
of each layer are identified as OpenStreetMap-Extremadura (base map), 
OpenStreetMap (topo) and Curvas de nivel (contour lines).
etrex 20x: only two maps are shown in map info: OpenStreetMap (base map) 
and OSM+Topo Extremadura (all layers). If only base map is enabled, 
background is black.
Edge 800: map info shows three maps, but they all have the same name and 
properties and it's necessary to enable/disable them by turns to know 
which is which.
As I've said, it was only one test and I probably have to play with 
description parameters to get a more homogeneous behavior, so any hint 
would be much appreciated.

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

Re: [mkgmap-dev] is_in filter

[Felix Hartmann]

well - that's why I think it should be precompiled. Do it once - no matter
if planet takes 48 hours on a potent machine - then redo it like every two
years... I do believe it will slow down mkgmap too much if compiled at the
same time as the maps themselves.

On 7 February 2017 at 22:41, Gerd Petermann  wrote:

> OK, got the idea. Not sure if that can be computed for planet in a
> reasonable time, but for a single tile it would not be too much.
>
> I have to think about this for a while.
>
> Gerd
> 
> Von: mkgmap-dev  im Auftrag von
> Felix Hartmann 
> Gesendet: Dienstag, 7. Februar 2017 22:20:04
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] is_in filter
>
> On 7 February 2017 at 21:54, Gerd Petermann  com> wrote:
>
> looks simple enough, but what would be the rule to set the new special
> tags like mkgmap:urban?
> Do you think those could be calculated somehow using only the data used to
> compile the bounds file?
> If yes, please give more details.
>
> well that's the hard part - I know. It could be a mix of several things -
> best I could think of is densitiy of POI or density of addresses.
>
> I'ld guess looking at density of POI and density of building=* - plus the
> bigger the size of the building the more it has to be assumed it's urban
> and some crosscheck with the bounds data would be enough. That should then
> end up in a static file just like sea data and bounds. It would also of
> course be possible to use that data to exclude buildings in cities - and
> more ideas.
>
> Even just density of POI and density of building=* (look at how much space
> the building occupies - e.g. if inside a squared area more than 20% of
> space is taken up by buildings - it's highly urban. 5-20% is a bit mixed,
> <5% is rural.
>
>
> --
> Felix Hartman - Openmtbmap.org & VeloMap.org
> Schusterbergweg 32/8
> 6020 Innsbruck
> Austria - Österreich
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>



-- 
Felix Hartman - Openmtbmap.org & VeloMap.org
Schusterbergweg 32/8
6020 Innsbruck
Austria - Österreich
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] is_in filter

[Gerd Petermann]

OK, got the idea. Not sure if that can be computed for planet in a reasonable 
time, but for a single tile it would not be too much.

I have to think about this for a while.

Gerd

Von: mkgmap-dev  im Auftrag von Felix 
Hartmann 
Gesendet: Dienstag, 7. Februar 2017 22:20:04
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] is_in filter

On 7 February 2017 at 21:54, Gerd Petermann 
> wrote:

looks simple enough, but what would be the rule to set the new special tags 
like mkgmap:urban?
Do you think those could be calculated somehow using only the data used to 
compile the bounds file?
If yes, please give more details.

well that's the hard part - I know. It could be a mix of several things - best 
I could think of is densitiy of POI or density of addresses.

I'ld guess looking at density of POI and density of building=* - plus the 
bigger the size of the building the more it has to be assumed it's urban and 
some crosscheck with the bounds data would be enough. That should then end up 
in a static file just like sea data and bounds. It would also of course be 
possible to use that data to exclude buildings in cities - and more ideas.

Even just density of POI and density of building=* (look at how much space the 
building occupies - e.g. if inside a squared area more than 20% of space is 
taken up by buildings - it's highly urban. 5-20% is a bit mixed, <5% is rural.


--
Felix Hartman - Openmtbmap.org & VeloMap.org
Schusterbergweg 32/8
6020 Innsbruck
Austria - Österreich
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] To do: If-Then-Else

[Andrzej Popowski]

Hi Gerd,

could you implement simple conditional statements, which would be 
analyzed at the stage of reading style? Similarly like statement 
"include" is processed.


I think the simplest version would contain 3 tokens:
ifdefined CONSTANT
ifnotdefined CONSTANT
endif

Scanner should look for ifdefined/ifnotdefined, check if CONSTANT exist 
and then analyze or skip rules until it finds token endif. It should 
support nesting. CONSTANT would be given as command line option. Or 
maybe even as an additional token, like "define CONSTANT".


--
Best regards,
Andrzej

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

Re: [mkgmap-dev] is_in filter

[nwillink]

For years now I have been keeping all buildings as a separate transparent
gmapsup /img  giving it a higher priority/draworder then my normal maps - It
has speeded up my daily runs without loss of detail - same could be done for
rivers/streams etc.
As a bonus I can ,if I wanted to, switch off/on buildings on my device, bit
like contours.
I update my buildings.img when necessary.

This is not an answer to the initial problem but it works

r

Nick



--
View this message in context: 
http://gis.19327.n8.nabble.com/is-in-filter-tp5890564p5890793.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

Re: [mkgmap-dev] To do: If-Then-Else

[Andrzej Popowski]

Hi Mike,

thanks for suggestion, this probably could be done. Currently I use some 
external scripts based on sed to create variants of my main style.


I think conditional statements, like the idea Gerd is considering, could 
be more flexible. I could get variants of style, that doesn't depend on 
OSM data. Like for example I could implement simple compile option for 
mkgmap, which decide if map contains buildings.


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

Re: [mkgmap-dev] is_in filter

[Gerd Petermann]

Hi Felix,

looks simple enough, but what would be the rule to set the new special tags 
like mkgmap:urban?
Do you think those could be calculated somehow using only the data used to 
compile the bounds file?
If yes, please give more details.

Gerd

Von: mkgmap-dev  im Auftrag von Felix 
Hartmann 
Gesendet: Dienstag, 7. Februar 2017 21:32:10
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] is_in filter

On 6 February 2017 at 21:45, Gerd Petermann 
> wrote:
this is probably a completely different problem. A highway=* way might be 
inside or outside some admin_level=*
boundary, but it may also cross one or more boundaries and it might be part of 
the boundary.
I think the bounds file contains all information needed to split the ways when 
needed.

Well I hoped that it would be splitted therefore at boundaries if needed.

e.g. I would do:
highway=cycleway & mkgmap:urban=yes [road_speed=1 road_class=0]
highway=cycleway & mkgmap:rural=yes [road_speed=2 road_class=4]
highway=cycleway & mkgmap:very_urban [road_speed=0 road_class=0]


Optimum would be to find cycleways which run in urban areas alongside roads and 
heavily downclass them - but I guess that is even less doable.


--
Felix Hartman - Openmtbmap.org & VeloMap.org
Schusterbergweg 32/8
6020 Innsbruck
Austria - Österreich
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] r3784 produces large img files than r3773

[Gerd Petermann]

Hi Ticker,

sounds to me as if this would produce only horizontal cut lines, possibly quite 
long and maybe
very close to each other. That would be correct but not good for further 
processing.

Gerd

Von: mkgmap-dev  im Auftrag von Ticker 
Berkin 
Gesendet: Dienstag, 7. Februar 2017 18:43:43
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] r3784 produces large img files than r3773

Hi Gerd

Algo:

Assumes list of outer polygons and list of inner ones;
Which inners go in each outer unknown.
No additional layers of nesting.

Best not to clipToBounds at start - complicates logic a lot.
Also assumed that this hasn't happened from map generation/splitting -
ie don't expect edge of inner to run along edge out outer.

Sort inners into order of top most point. Note this point
   (if more than 1 equal top point, remember L outermost)
For each inner:
  For each outer:
Make a test cut of outer across the line of inner top
If resulted in >1 piece
  look through lower pieces for segment that follows cut line and
   encompasses the top of the inner
  if found
note l distances from inner to ends of cut segment
choose shorter and note end coord=x and 1 away from the cut=y
go back to orig outer, find coord y
depending on the outer direction and side make y prev coord
// Now can insert the cut and inner after y:
unclose inner
reverse if same area/sign as outer
rotate so that start is at top (l/r if appropriate)
add these coords to orig outer after coord y:
   x, all inner, inner first coord, x
break
  end for each outer
  error - didn't find outer for inner
end for each inner

That's it. Slight adjustments need to be made if x happens to be an
original coordinate rather than one invented by ShapeSplitter

Ticker


On Tue, 2017-02-07 at 16:44 +, Gerd Petermann wrote:
> Hi Ticker,
>
> I'd prefer to get a patch for MultipolygonCutter ;-)
> I guess the problems are similar to those in the split algo.
> Pseudo-Code for an alternative solution is also welcomed.
>
> FYI: I am implementing an index that allows to quickly find nearby
> way segments , I will use that to find intersections in mp-rels
> in the same way as I've implemented it with some patches for JOSM.
> The index might be useful for my cut algo as well.
>
> Gerd
> 
> Von: mkgmap-dev  im Auftrag
> von Ticker Berkin 
> Gesendet: Dienstag, 7. Februar 2017 14:34:36
> An: mkgmap-dev@lists.mkgmap.org.uk
> Betreff: Re: [mkgmap-dev] r3784 produces large img files than r3773
>
> Hi Gerd
>
> orderByDecreasingArea only has a param declaration and single use in
> MapSplitter and its value transforms to MapArea.splitPolygonsIntoArea
> so I think it is better as it is.
>
> I had some thoughts on a simple/efficient algo for
> MultiPolygonRelation
> hole cutting - It won't produce the optimized cuts that yours is
> aiming
> for. If you are interested, I'll formulate some pseudo-code.
>
> Merge the branch whenever is best for you.
>
> Ticker
>
> On Tue, 2017-02-07 at 13:12 +, Gerd Petermann wrote:
> > Hi Ticker,
> >
> > thanks, I am still working a new algos to replace parts of the
> > existing code in MultipolygonRelation,
> > esp. that for createContainsMatrix(). I hope to finish the first
> > patch tomorrow.
> > If that takes much longer I plan to merge the branch into trunk
> > first.
> > Reg. refactoring: What do you think about adding
> > orderByDecreasingArea as a (final) field in MapSplitter?
> >
> > Gerd
> >
> >
> > 
> > Von: mkgmap-dev  im Auftrag
> > von Ticker Berkin 
> > Gesendet: Dienstag, 7. Februar 2017 13:45:25
> > An: mkgmap-dev@lists.mkgmap.org.uk
> > Betreff: Re: [mkgmap-dev] r3784 produces large img files than r3773
> >
> > Done
> >
> > On Tue, 2017-02-07 at 12:17 +, Gerd Petermann wrote:
> > > Hi Ticker,
> > >
> > > that's what I expected. Most shapes do not have too many  points
> > > after line simplification.
> > > If I got that right most of the code in PolygonSplitterFilter is
> > > now
> > > obsolete. I think it would be
> > > better to move the functionality of PolygonSplitIfNeededFilter
> > > into
> > > it so that the history is kept.
> > >
> > > Gerd
> >
> > ___
> > 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
> 

Re: [mkgmap-dev] r3784 produces large img files than r3773

[Ticker Berkin]

Hi Gerd

Algo:

Assumes list of outer polygons and list of inner ones;
Which inners go in each outer unknown.
No additional layers of nesting.

Best not to clipToBounds at start - complicates logic a lot.
Also assumed that this hasn't happened from map generation/splitting -
ie don't expect edge of inner to run along edge out outer.

Sort inners into order of top most point. Note this point
   (if more than 1 equal top point, remember L outermost)
For each inner:
  For each outer:
Make a test cut of outer across the line of inner top
If resulted in >1 piece
  look through lower pieces for segment that follows cut line and
   encompasses the top of the inner
  if found
note l distances from inner to ends of cut segment
choose shorter and note end coord=x and 1 away from the cut=y
go back to orig outer, find coord y
depending on the outer direction and side make y prev coord
// Now can insert the cut and inner after y:
unclose inner
reverse if same area/sign as outer
rotate so that start is at top (l/r if appropriate)
add these coords to orig outer after coord y:
   x, all inner, inner first coord, x
break
  end for each outer
  error - didn't find outer for inner
end for each inner

That's it. Slight adjustments need to be made if x happens to be an
original coordinate rather than one invented by ShapeSplitter

Ticker


On Tue, 2017-02-07 at 16:44 +, Gerd Petermann wrote:
> Hi Ticker,
> 
> I'd prefer to get a patch for MultipolygonCutter ;-)
> I guess the problems are similar to those in the split algo.
> Pseudo-Code for an alternative solution is also welcomed.
> 
> FYI: I am implementing an index that allows to quickly find nearby
> way segments , I will use that to find intersections in mp-rels
> in the same way as I've implemented it with some patches for JOSM.
> The index might be useful for my cut algo as well.
> 
> Gerd
> 
> Von: mkgmap-dev  im Auftrag
> von Ticker Berkin 
> Gesendet: Dienstag, 7. Februar 2017 14:34:36
> An: mkgmap-dev@lists.mkgmap.org.uk
> Betreff: Re: [mkgmap-dev] r3784 produces large img files than r3773
> 
> Hi Gerd
> 
> orderByDecreasingArea only has a param declaration and single use in
> MapSplitter and its value transforms to MapArea.splitPolygonsIntoArea
> so I think it is better as it is.
> 
> I had some thoughts on a simple/efficient algo for
> MultiPolygonRelation
> hole cutting - It won't produce the optimized cuts that yours is
> aiming
> for. If you are interested, I'll formulate some pseudo-code.
> 
> Merge the branch whenever is best for you.
> 
> Ticker
> 
> On Tue, 2017-02-07 at 13:12 +, Gerd Petermann wrote:
> > Hi Ticker,
> > 
> > thanks, I am still working a new algos to replace parts of the
> > existing code in MultipolygonRelation,
> > esp. that for createContainsMatrix(). I hope to finish the first
> > patch tomorrow.
> > If that takes much longer I plan to merge the branch into trunk
> > first.
> > Reg. refactoring: What do you think about adding
> > orderByDecreasingArea as a (final) field in MapSplitter?
> > 
> > Gerd
> > 
> > 
> > 
> > Von: mkgmap-dev  im Auftrag
> > von Ticker Berkin 
> > Gesendet: Dienstag, 7. Februar 2017 13:45:25
> > An: mkgmap-dev@lists.mkgmap.org.uk
> > Betreff: Re: [mkgmap-dev] r3784 produces large img files than r3773
> > 
> > Done
> > 
> > On Tue, 2017-02-07 at 12:17 +, Gerd Petermann wrote:
> > > Hi Ticker,
> > > 
> > > that's what I expected. Most shapes do not have too many  points
> > > after line simplification.
> > > If I got that right most of the code in PolygonSplitterFilter is
> > > now
> > > obsolete. I think it would be
> > > better to move the functionality of PolygonSplitIfNeededFilter
> > > into
> > > it so that the history is kept.
> > > 
> > > Gerd
> > 
> > ___
> > 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] To do: If-Then-Else

[Mike Baggaley]

Hi Andrzej, can you not make use of mkgmap:country to handle this scenario?

mkgmap:country=DZA | mkgmap:country=AGO |  mkgmap:country=SHN |
mkgmap:country=BEN ... {set continent=AF}

continent=AF & landuse=farmland [0x10f01 level 1]

Would mkgmap be better with a mkgmap:continent variable using
place=continent added?

Regards,
Mike

-Original Message-
From: Andrzej Popowski [mailto:po...@poczta.onet.pl] 
Sent: 07 February 2017 12:39
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] To do: If-Then-Else

Hi Dave,

I think the idea is to include some preprocessing capability to style 
interpreter.

I develop a single style for my topo maps, but I need some possibility 
to get a small variation in style depending on region. For example I 
prefer to show landuse=farmland on a map of Africa but to remove it on a 
map of Europe. So instead of maintaining 2 nearly identical styles, I 
would like to get a conditional statement, something like:

if (SHOW_FARMS) (
landuse=farmland [0x10f01 level 1]
)

and then add (or not) an option to mkgmap like --style-define=SHOW_FARMS

-- 
Best regards,
Andrzej


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

Re: [mkgmap-dev] r3784 produces large img files than r3773

[Gerd Petermann]

Hi Ticker,

I'd prefer to get a patch for MultipolygonCutter ;-)
I guess the problems are similar to those in the split algo.
Pseudo-Code for an alternative solution is also welcomed.

FYI: I am implementing an index that allows to quickly find nearby
way segments , I will use that to find intersections in mp-rels
in the same way as I've implemented it with some patches for JOSM.
The index might be useful for my cut algo as well.

Gerd

Von: mkgmap-dev  im Auftrag von Ticker 
Berkin 
Gesendet: Dienstag, 7. Februar 2017 14:34:36
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] r3784 produces large img files than r3773

Hi Gerd

orderByDecreasingArea only has a param declaration and single use in
MapSplitter and its value transforms to MapArea.splitPolygonsIntoArea
so I think it is better as it is.

I had some thoughts on a simple/efficient algo for MultiPolygonRelation
hole cutting - It won't produce the optimized cuts that yours is aiming
for. If you are interested, I'll formulate some pseudo-code.

Merge the branch whenever is best for you.

Ticker

On Tue, 2017-02-07 at 13:12 +, Gerd Petermann wrote:
> Hi Ticker,
>
> thanks, I am still working a new algos to replace parts of the
> existing code in MultipolygonRelation,
> esp. that for createContainsMatrix(). I hope to finish the first
> patch tomorrow.
> If that takes much longer I plan to merge the branch into trunk
> first.
> Reg. refactoring: What do you think about adding
> orderByDecreasingArea as a (final) field in MapSplitter?
>
> Gerd
>
>
> 
> Von: mkgmap-dev  im Auftrag
> von Ticker Berkin 
> Gesendet: Dienstag, 7. Februar 2017 13:45:25
> An: mkgmap-dev@lists.mkgmap.org.uk
> Betreff: Re: [mkgmap-dev] r3784 produces large img files than r3773
>
> Done
>
> On Tue, 2017-02-07 at 12:17 +, Gerd Petermann wrote:
> > Hi Ticker,
> >
> > that's what I expected. Most shapes do not have too many  points
> > after line simplification.
> > If I got that right most of the code in PolygonSplitterFilter is
> > now
> > obsolete. I think it would be
> > better to move the functionality of PolygonSplitIfNeededFilter into
> > it so that the history is kept.
> >
> > Gerd
>
> ___
> 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] r3784 produces large img files than r3773

[Ticker Berkin]

Hi Gerd

orderByDecreasingArea only has a param declaration and single use in
MapSplitter and its value transforms to MapArea.splitPolygonsIntoArea
so I think it is better as it is.

I had some thoughts on a simple/efficient algo for MultiPolygonRelation
hole cutting - It won't produce the optimized cuts that yours is aiming
for. If you are interested, I'll formulate some pseudo-code.

Merge the branch whenever is best for you.

Ticker

On Tue, 2017-02-07 at 13:12 +, Gerd Petermann wrote:
> Hi Ticker,
> 
> thanks, I am still working a new algos to replace parts of the
> existing code in MultipolygonRelation,
> esp. that for createContainsMatrix(). I hope to finish the first
> patch tomorrow.
> If that takes much longer I plan to merge the branch into trunk
> first.
> Reg. refactoring: What do you think about adding
> orderByDecreasingArea as a (final) field in MapSplitter?
> 
> Gerd
> 
> 
> 
> Von: mkgmap-dev  im Auftrag
> von Ticker Berkin 
> Gesendet: Dienstag, 7. Februar 2017 13:45:25
> An: mkgmap-dev@lists.mkgmap.org.uk
> Betreff: Re: [mkgmap-dev] r3784 produces large img files than r3773
> 
> Done
> 
> On Tue, 2017-02-07 at 12:17 +, Gerd Petermann wrote:
> > Hi Ticker,
> > 
> > that's what I expected. Most shapes do not have too many  points
> > after line simplification.
> > If I got that right most of the code in PolygonSplitterFilter is
> > now
> > obsolete. I think it would be
> > better to move the functionality of PolygonSplitIfNeededFilter into
> > it so that the history is kept.
> > 
> > Gerd
> 
> ___
> 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] r3784 produces large img files than r3773

[Gerd Petermann]

Hi Ticker,

thanks, I am still working a new algos to replace parts of the existing code in 
MultipolygonRelation,
esp. that for createContainsMatrix(). I hope to finish the first patch tomorrow.
If that takes much longer I plan to merge the branch into trunk first.
Reg. refactoring: What do you think about adding orderByDecreasingArea as a 
(final) field in MapSplitter?

Gerd



Von: mkgmap-dev  im Auftrag von Ticker 
Berkin 
Gesendet: Dienstag, 7. Februar 2017 13:45:25
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] r3784 produces large img files than r3773

Done

On Tue, 2017-02-07 at 12:17 +, Gerd Petermann wrote:
> Hi Ticker,
>
> that's what I expected. Most shapes do not have too many  points
> after line simplification.
> If I got that right most of the code in PolygonSplitterFilter is now
> obsolete. I think it would be
> better to move the functionality of PolygonSplitIfNeededFilter into
> it so that the history is kept.
>
> Gerd

___
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] r3784 produces large img files than r3773

[Ticker Berkin]

Done

On Tue, 2017-02-07 at 12:17 +, Gerd Petermann wrote:
> Hi Ticker,
> 
> that's what I expected. Most shapes do not have too many  points
> after line simplification.
> If I got that right most of the code in PolygonSplitterFilter is now
> obsolete. I think it would be
> better to move the functionality of PolygonSplitIfNeededFilter into
> it so that the history is kept.
> 
> Gerd

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

Re: [mkgmap-dev] To do: If-Then-Else

[Andrzej Popowski]

Hi Dave,

I think the idea is to include some preprocessing capability to style 
interpreter.


I develop a single style for my topo maps, but I need some possibility 
to get a small variation in style depending on region. For example I 
prefer to show landuse=farmland on a map of Africa but to remove it on a 
map of Europe. So instead of maintaining 2 nearly identical styles, I 
would like to get a conditional statement, something like:


if (SHOW_FARMS) (
landuse=farmland [0x10f01 level 1]
)

and then add (or not) an option to mkgmap like --style-define=SHOW_FARMS

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

Re: [mkgmap-dev] r3784 produces large img files than r3773

[Gerd Petermann]

Hi Ticker,

that's what I expected. Most shapes do not have too many  points after line 
simplification.
If I got that right most of the code in PolygonSplitterFilter is now obsolete. 
I think it would be
better to move the functionality of PolygonSplitIfNeededFilter into it so that 
the history is kept.

Gerd

Von: mkgmap-dev  im Auftrag von Ticker 
Berkin 
Gesendet: Dienstag, 7. Februar 2017 12:49:02
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] r3784 produces large img files than r3773

Hi Gerd

I've done this and committed. In the examples I found, using
backtracking to split the polygon gave very slight size improvements
(best was about 0.05%)

Ticker

On Sat, 2017-02-04 at 06:10 -0700, Gerd Petermann wrote:
> Hi Ticker,
>
> Ticker Berkin wrote
> > I can't do anything for a couple of days but I'd like to combine
> > the
> > methods.
>
> sounds good to me. I once analysed why sub divs were split and found
> that
> most times it was because of "too many points" or "too many lines",
> not
> because
> of "too much data in rgn", but that might depend on style.
>
> Gerd
>
>
>
> --
> View this message in context: http://gis.19327.n8.nabble.com/r3784-pr
> oduces-large-img-files-than-r3773-tp5890509p5890561.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
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] unpaved roads

[Gerd Petermann]

Hi Nuno,

you are welcome!
My understanding is that everybody who thinks about the "avoid unpaved roads" 
feature in Garmin units a bit longer will come to the solution that they have 
to either
accept what the preferred style is doing or else to fork an own version of that 
style (assuming that this is allowed).
Many rules in the default style assume that you are in a rather developed 
country, I think they work very good for countries where traffic is similar to 
Germany or the UK regarding
the interpretation of highway types like tertiary, secondary etc, probably not 
so well for many countries outside Europe.

Gerd

Von: mkgmap-dev  im Auftrag von Nuno 
Pedrosa 
Gesendet: Dienstag, 7. Februar 2017 11:57:13
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] unpaved roads

Hi! In Portugal, Spain and surely a little all around, unpaved gravel roads are 
common, even on urban neighbourhoods.
These are quite drivable and they will often be the only way to get to some 
places. They are also suitable to all vehicles, even if they will get covered 
in dirt.
There are also a lot of paths going through sand (forest roads) and these will 
unsuitable to most vehicles (even a lot of 4x4s), regardless of their width.

I find that while driving, the real issue will be the road conditions and 
width. Will the unpaved road be wide enough for a car or light truck? Will it 
have deep tracks due to soil erosion? Will the surface be solid enough to drive 
in a regular car?

So, in real world GPS usage, I would like unpaved to mean “narrow, earth 
roads”, while paved would mean any road suitable to all regular vehicles.
Example: due to wind farms being built in a lot of hill ranges, large, unpaved 
roads were built. These are gravel, wide roads, and often are a better option 
to the paved, sinuous mountain roads that go around every nook and cranny in 
the valleys.

So, I think that fine_gravel, salt and ice should still be “paved”.

Nuno Pedrosa.

PS: Sorry to “butt in” the talk. I’m usually silent in this list, though I read 
most of the discussions. Your work is amazing and I find that I can add little 
to what is being discussed, so I try to keep my “noise” to a minimum!


On 7 Feb 2017, at 09:40, lig fietser 
> wrote:

I'd call that semi-paved but Garmin doesn't have such category unfortunately. 
Since the default style main focus is on motor vehicles I'd suggest to add 
surfaces like fine_gravel, salt, ice to the unpaved list. And please add soil 
to it, it seems a quite popular tag.


Gerd wrote
This "raining" part is probably what paved/unpaved is about: The surface of a 
paved road should not change when it's raining
and your vehicle will not be covered with dirt when traveling on a paved road 
while it is raining (at least not from dirt which was part of the surface).

Do you agree on that (last sentence)?

Gerd


___
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] unpaved roads

[Nuno Pedrosa]

Hi! In Portugal, Spain and surely a little all around, unpaved gravel roads are 
common, even on urban neighbourhoods.
These are quite drivable and they will often be the only way to get to some 
places. They are also suitable to all vehicles, even if they will get covered 
in dirt.
There are also a lot of paths going through sand (forest roads) and these will 
unsuitable to most vehicles (even a lot of 4x4s), regardless of their width. 

I find that while driving, the real issue will be the road conditions and 
width. Will the unpaved road be wide enough for a car or light truck? Will it 
have deep tracks due to soil erosion? Will the surface be solid enough to drive 
in a regular car?

So, in real world GPS usage, I would like unpaved to mean “narrow, earth 
roads”, while paved would mean any road suitable to all regular vehicles.
Example: due to wind farms being built in a lot of hill ranges, large, unpaved 
roads were built. These are gravel, wide roads, and often are a better option 
to the paved, sinuous mountain roads that go around every nook and cranny in 
the valleys.

So, I think that fine_gravel, salt and ice should still be “paved”.

Nuno Pedrosa.

PS: Sorry to “butt in” the talk. I’m usually silent in this list, though I read 
most of the discussions. Your work is amazing and I find that I can add little 
to what is being discussed, so I try to keep my “noise” to a minimum!


> On 7 Feb 2017, at 09:40, lig fietser  wrote:
> 
> I'd call that semi-paved but Garmin doesn't have such category unfortunately. 
> Since the default style main focus is on motor vehicles I'd suggest to add 
> surfaces like fine_gravel, salt, ice to the unpaved list. And please add soil 
> to it, it seems a quite popular tag.
> 
> Gerd wrote
> This "raining" part is probably what paved/unpaved is about: The surface of a 
> paved road should not change when it's raining
> and your vehicle will not be covered with dirt when traveling on a paved road 
> while it is raining (at least not from dirt which was part of the surface).
> 
> Do you agree on that (last sentence)?
> 
> Gerd
> 
>  
> ___
> 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] unpaved roads

[Dave Swarthout]

I have never mapped any myself. Mostly, AFAIK, ice roads are used by large
vehicles on the North Slope of Alaska where they haul supplies to the oil
fields or out to wellheads in the Arctic Ocean. There are only three in
Alaska, two are service roads, one uses the ice_road=yes tag, the other
surface=ice while the last is actually a ferry route on a frozen river.
That one was tagged with ice_road=yes and surface=ice_road. I changed the
surface tag to surface=ice and left the other tags as is but I don't think
tagging a ferry route as an ice_road is correct.

As for tagging, I would consider them unpaved at the minimum because IMO
drivers of ordinary vehicles would generally want to avoid them. In the
case of the oil field service roads, those are most likely restricted
(acess=private) anyway so shouldn't be used in a routing scenario. Your
ice_road rule looks good to me and sidesteps the question of setting them
to unpaved nicely.

I found your full surface rule and inserted it into my lines style sheet
instead of the one I had been using.

Thank you.

On Tue, Feb 7, 2017 at 4:08 PM, lig fietser  wrote:

> Talking about surface=ice, how do we handle ice_road=yes? Those roads are
> common in the Arctic regions and cross frozen lakes, so only accessible in
> winter. See http://overpass-turbo.eu/s/ls3
>
> In the generic new style map I made those roads unroutable.
> https://github.com/ligfietser/mkgmap-style-sheets/blob/
> master/styles/generic%20new/lines
> highway=* & ice_road=yes { addlabel 'ice road' } [0x10002 resolution 24]
>
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>



-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] unpaved roads

[lig fietser]

I'd call that semi-paved but Garmin doesn't have such category unfortunately. 
Since the default style main focus is on motor vehicles I'd suggest to add 
surfaces like fine_gravel, salt, ice to the unpaved list. And please add soil 
to it, it seems a quite popular tag.


Gerd wrote
This "raining" part is probably what paved/unpaved is about: The surface of a 
paved road should not change when it's raining
and your vehicle will not be covered with dirt when traveling on a paved road 
while it is raining (at least not from dirt which was part of the surface).

Do you agree on that (last sentence)?

Gerd


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

Re: [mkgmap-dev] unpaved roads

[Gerd Petermann]

Yes, quite difficult.
My understanding is that we don't really care about paved/unpaved here, it is 
more about smoothness, and probably most of the people contributing here are 
cyclists.
I've cycled > 33.000 km through many European countries during the last years 
and I'd prefer to avoid surface
cobblestone or concrete:plates which are "paved" but painful
while I really like to travel on fine_gravel as long as it is not raining 
heavily.
On the racing bike I'd prefer to avoid surfaces which are not smooth, but I 
nearly stopped cycling on them.

This "raining" part is probably what paved/unpaved is about: The surface of a 
paved road should not change when it's raining
and your vehicle will not be covered with dirt when traveling on a paved road 
while it is raining (at least not from dirt which was part of the surface).

Do you agree on that (last sentence)?

Gerd





Von: mkgmap-dev  im Auftrag von lig 
fietser 
Gesendet: Dienstag, 7. Februar 2017 09:38:03
An: Development list for mkgmap; daveswarth...@gmail.com
Betreff: Re: [mkgmap-dev] unpaved roads

It really depends on the user, the region etc.

In my bicycle map I consider fine_gravel cycleways as paved because my users 
are mainly touring cyclists and those paths are (at least in my region) 
excellent for touring. But not suitable for racing bicycles, for them those 
cycleways  are unpaved.


I would suggest to make it unpaved for generic use and use a regular expression 
sytax to catch all combinations. In my OFM I solved this by using


surface ~ 
'.*(ash|bad|clay|cob|compact|dirt|earth|erde|gr|loam|mud|peb|sand|shotter|rock|turf|unpaved).*'




Dave wrote:

But none are "paved" in the usual sense of that word. I would hate to drive on 
a "fine gravel" road, or an ice road, unless I was prepared for it. Even if the 
fine gravel were on top of a compacted substrate it would present a hazard to 
bicycles and motorcycles. I'm not sure I care how a "salt" road is classified - 
I've never seen one let alone driven on one.


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

Re: [mkgmap-dev] unpaved roads

[lig fietser]

It really depends on the user, the region etc.

In my bicycle map I consider fine_gravel cycleways as paved because my users 
are mainly touring cyclists and those paths are (at least in my region) 
excellent for touring. But not suitable for racing bicycles, for them those 
cycleways  are unpaved.


I would suggest to make it unpaved for generic use and use a regular expression 
sytax to catch all combinations. In my OFM I solved this by using


surface ~ 
'.*(ash|bad|clay|cob|compact|dirt|earth|erde|gr|loam|mud|peb|sand|shotter|rock|turf|unpaved).*'




Dave wrote:

But none are "paved" in the usual sense of that word. I would hate to drive on 
a "fine gravel" road, or an ice road, unless I was prepared for it. Even if the 
fine gravel were on top of a compacted substrate it would present a hazard to 
bicycles and motorcycles. I'm not sure I care how a "salt" road is classified - 
I've never seen one let alone driven on one.


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

[mkgmap-dev] To do: If-Then-Else

[Dave Swarthout]

I came across the mkgmap ToDo list the other day and one item struck me as
something I would really like to see in a coming release. The ability to
evaluate If-Then-Else constructs would make writing, evaluating and
debugging style rules so much easier.

+1 on this item

Also, a little clarification please. The list item says:

   - conditional includes in style files and/or if else statements

I don't understand this statement. Perhaps it's because I'm assuming a
"conditional include" means:

If (condition) Then include 'inc/address';

Or does it mean, for example,

If (condition) { add mkgmap:unpaved=1 }

Thank you in advance.

AlaskaDave

-- Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev