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
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
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.
___
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 simpli
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 rule
Hi,
I like your ideas about is_in and urban areas. But I have doubts about
practical results. IMO areas like landuse=residential or place=city/town
aren't mapped well in OSM data. So even if you add some new features to
mkgmap, it won't be useful, because input data is not precise.
Some cons
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 th
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
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
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 Peter
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. Februa
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 ifde
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.
>
we
Version mkgmap-r3792 was committed by gerd on Tue, 07 Feb 2017
make sure that pbf header contains bbox before trying to read it
http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3792
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.
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 bui
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
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: mkgma
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
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:
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
Hi,
don't know if this helps:
I see one possible implementation for a conditional rule like
if () {
some rules
} else {
other rules
}
where would be something like tag=val, maybe also a parameter given to
the program.
If someone knows how to implement the syntax parser for such an if-thent-else
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
pl
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 intersec
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 optimize
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 th
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
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 re
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
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 cou
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
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 th
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
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
surfac
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.
___
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
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-s
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 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 clarificatio
38 matches
Mail list logo
