Re: [mkgmap-dev] compat_lines

[Gerd Petermann]

Hi Dave,


the compat_* files are kept to help style authors adapt their styles to changes

introduced with r2906 back in 2012.  Please check

http://www.mkgmap.org.uk/news/2013/12/22/more-flexibility-in-style-files-style




The default style was adapted and does not need these files.


Gerd


Von: mkgmap-dev  im Auftrag von Dave 
Swarthout 
Gesendet: Dienstag, 26. Juli 2016 01:43:24
An: Development list for mkgmap
Betreff: [mkgmap-dev] compat_lines

I'm working on trying to add the maxspeed tag value to my highways by creating 
or modifying style directives. In my investigations I noticed that the file 
compat_lines is not being called by any of my style files. Also, the default 
styles don't seem to use or call it either. Why is it present then? Or am I 
just missing a call that includes it somewhere else?

Thanks,
Dave
--
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

[mkgmap-dev] compat_lines

[Dave Swarthout]

I'm working on trying to add the maxspeed tag value to my highways by
creating or modifying style directives. In my investigations I noticed that
the file compat_lines is not being called by any of my style files. Also,
the default styles don't seem to use or call it either. Why is it present
then? Or am I just missing a call that includes it somewhere else?

Thanks,
Dave
-- 
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] tagging/rendering ways with multiple relations

[Andy Townsend]

Just for info - you've sent this to the mkgmap-dev list, which I suspect 
might not have been deliberate.  That list is all about creating Garmin 
maps using OSM data; not really how to tag trails.


It sounds like a good candidate question for the help site 
https://help.openstreetmap.org , actually!


While none of the 4 map styles on the osm.org website currently display 
hiking route relations there are others that do.  You've already 
mentioned "waymarked trails"; Thunderforest Outdoors is another example 
http://www.thunderforest.com/maps/outdoors/ .


The "issues list" for the standard map style is at 
https://github.com/gravitystorm/openstreetmap-carto/issues .  It 
wouldn't surprise me if someone has already added one for "please 
dispplay hiking routes".


For various technical reasons it might be difficult to show relation 
membership on OSM's "standard map", but if you want to you can use a bit 
of browser trickery to show different map tiles in place of one of the 4 
normal map styles: 
http://wiki.openstreetmap.org/wiki/User:SomeoneElse/Your_tiles_from_osm.org 
.  It's also possible (but a bit harder) to create your own map tiles - 
for example here's an example I did based on OSM's "standard" map from a 
couple of years ago: 
https://www.openstreetmap.org/user/SomeoneElse/diary/38988 .


To actually answer the questions:

 * What is the best practice in dealing with such a situation?

Don't try and munge the "route name" into the "path or street name", but 
add it to the route relation.


 * Should I be adding the contents of every relation tag associated
   with a way, to the name tag of the way?  This seems like it would be
   very cumbersome.

It would indeed be cumbersome, and not a good idea.

 * Would it make sense to have the default openstreetmap.org page
   render the name tag of each associated  relation and if there are no
   relations then render the name tag of the way itself?

Possibly, but the challenge is that there are lots of different sorts of 
data competing to be rendered, and if you try and render _everything_ 
you end up with a mess.  Also, as I mentioned above there are technical 
restrictions to do with what's in the standard map's rendering database 
that controls what can be displayed currently.  There are plans afoot to 
change that though - to move to using lua tag transforms that allow 
processing similar in many ways to what you can do with mkgmap's style 
files.


Cheers,
Andy


On 25/07/16 19:59, 987654...@use.startmail.com wrote:


Hi

I have been learning OSM mapping now for a while and struggle with 
best practices for name tagging ways. As an example please view the 
1779 Trail on which I have worked which is shared in part by the 1777W 
Trail, the Timp Torne Trail links included below.


What I have done here is

  * created a relation for each of the individual trails adding the
name of the trail to the relation name.
  * leave the name tag on the way blank.

However a problem arises:

On waymarked trails this portion of the trail is rendered as follows:
http://hiking.waymarkedtrails.org/#route?id=6292324&map=18!41.3237!-73.9884
showing symbols for the 3 trails that the way.

On openstreetmap.org it is rendered as follows:
https://www.openstreetmap.org/#map=19/41.32387/-73.98884
showing neither the symbols or the 3 associated trailnames.

I am wondering 2 things

  * What is the best practice in dealing with such a situation?
  * Should I be adding the contents of every relation tag associated
with a way, to the name tag of the way?  This seems like it would
be very cumbersome.
  * Would it make sense to have the default openstreetmap.org page
render the name tag of each associated  relation and if there are
no relations then render the name tag of the way itself?

Bill


___
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] tagging/rendering ways with multiple relations

[987654321]

Hi

I have been learning OSM mapping now for a while and struggle with best
practices for name tagging ways. As an example please view the 1779
Trail on which I have worked which is shared in part by the 1777W Trail,
the Timp Torne Trail links included below.

What I have done here is

  * created a relation for each of the individual trails adding the name
of the trail to the relation name.
  * leave the name tag on the way blank.

However a problem arises:

On waymarked trails this portion of the trail is rendered as follows:
http://hiking.waymarkedtrails.org/#route?id=6292324&map=18!41.3237!-73.9884
showing symbols for the 3 trails that the way.

On openstreetmap.org it is rendered as follows:
https://www.openstreetmap.org/#map=19/41.32387/-73.98884
showing neither the symbols or the 3 associated trailnames.

I am wondering 2 things

  * What is the best practice in dealing with such a situation?
  * Should I be adding the contents of every relation tag associated
with a way, to the name tag of the way?  This seems like it would be
very cumbersome.
  * Would it make sense to have the default openstreetmap.org page
render the name tag of each associated  relation and if there are no
relations then render the name tag of the way itself?

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

Re: [mkgmap-dev] Why do we render place=island polygons in the default style?

[Gerd Petermann]

Maybe it would be better to move the rule for

place=island

after the rules in

include inc/landuse_polygons .
Many polygons are tagged with place=island and landuse=* or natural=*
and I think that is the more important info.

Gerd





Von: mkgmap-dev  im Auftrag von Gerd 
Petermann 
Gesendet: Montag, 25. Juli 2016 19:37:28
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Why do we render place=island polygons in the default 
style?


Hi Andrzej,


I am not sure what tags are copied in the mp code,

but if the answer is "no" it will do no harm besides that

the island is rendered, which always happens now.


Gerd


Von: mkgmap-dev  im Auftrag von Andrzej 
Popowski 
Gesendet: Montag, 25. Juli 2016 18:49:21
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] Why do we render place=island polygons in the default 
style?

Hi Gerd,

island is a relation (multipolygon) while natural=coastline is a tag
from a line, not from relation. Would mkgmap find this tag when
processing multipolygon?

--
Best regards,
Andrzej
___
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] Why do we render place=island polygons in the default style?

[Gerd Petermann]

Hi Andrzej,


I am not sure what tags are copied in the mp code,

but if the answer is "no" it will do no harm besides that

the island is rendered, which always happens now.


Gerd


Von: mkgmap-dev  im Auftrag von Andrzej 
Popowski 
Gesendet: Montag, 25. Juli 2016 18:49:21
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] Why do we render place=island polygons in the default 
style?

Hi Gerd,

island is a relation (multipolygon) while natural=coastline is a tag
from a line, not from relation. Would mkgmap find this tag when
processing multipolygon?

--
Best regards,
Andrzej
___
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] Why do we render place=island polygons in the default style?

[Andrzej Popowski]

Hi Gerd,

island is a relation (multipolygon) while natural=coastline is a tag 
from a line, not from relation. Would mkgmap find this tag when 
processing multipolygon?


--
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] Possible bug in index creation

[Gerd Petermann]

Hi Carlos,


I noticed this problem before in other situations. My understanding

is that city names are collected from different sources, sometimes we

have additional info from a POI, sometimes we don't. If I got that right

the index will have two entries when a city name is derived from e.g. the

housenumber processing. I don't know why this is done, but their is special

code for this, so it seems to be intended.

I don't know why you see the problem only with the extra rules. Maybe

a different spelling in e.g. one addr:city ?


Gerd


Von: mkgmap-dev  im Auftrag von Carlos 
Dávila 
Gesendet: Montag, 25. Juli 2016 17:04:20
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Possible bug in index creation

Any idea about this issue?


El 19/07/16 a las 18:38, Carlos Dávila escribió:
> In my style I have two extra lines to set mkgmap:city in Spain before
> default one:
> mkgmap:country=ESP & mkgmap:city!=* & is_in:city=* { set
> mkgmap:city='${is_in:city}' }
> mkgmap:country=ESP & mkgmap:city!=* & addr:city=* { set
> mkgmap:city='${addr:city}' }
> mkgmap:country=ESP & mkgmap:city!=* & mkgmap:admin_level8=* { set
> mkgmap:city='${mkgmap:admin_level8}' }
>
> The presence of any of those lines causes that when you search for an
> address in device and are promted for a city, some cities appear
> twice. If you select one of them no street is found and if you select
> the other one streets are found normally.
> Test file: http://mapas.alternativaslibres.es/extremadura.o5m
> Searching for an address in Cáceres city shows "Cáceres, provincia de
> Cáceres" twice.
___
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] Possible bug in index creation

[Carlos Dávila]

Any idea about this issue?


El 19/07/16 a las 18:38, Carlos Dávila escribió:
In my style I have two extra lines to set mkgmap:city in Spain before 
default one:
mkgmap:country=ESP & mkgmap:city!=* & is_in:city=* { set 
mkgmap:city='${is_in:city}' }
mkgmap:country=ESP & mkgmap:city!=* & addr:city=* { set 
mkgmap:city='${addr:city}' }
mkgmap:country=ESP & mkgmap:city!=* & mkgmap:admin_level8=* { set 
mkgmap:city='${mkgmap:admin_level8}' }


The presence of any of those lines causes that when you search for an 
address in device and are promted for a city, some cities appear 
twice. If you select one of them no street is found and if you select 
the other one streets are found normally.
Test file: http://mapas.alternativaslibres.es/extremadura.o5m 
Searching for an address in Cáceres city shows "Cáceres, provincia de 
Cáceres" twice.

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

Re: [mkgmap-dev] Why do we render place=island polygons in the default style?

[Gerd Petermann]

Hi Andrzej


sure, we want to have the POI, I don't want to touch the rules in points.

Reg. coastline: My thinking is that we can ignore even small islands when they 
have

the natural=coastline attribute, so something like


place=island & name=* & area_size() < 100 & !(natural=coastline) [0x53 
resolution 19]


Gerd


Von: mkgmap-dev  im Auftrag von Andrzej 
Popowski 
Gesendet: Montag, 25. Juli 2016 15:22:26
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] Why do we render place=island polygons in the default 
style?

Hi Gerd,

I guess there could exist instances, where sea/lake doesn't include a
hole and island can be overlaid over water. But these are errors easy to
correct in OSM data. Other function for these objects is to add a label
to an area.

In my styles I have removed islands from polygons but left them as a
POI. From your suggestions I would prefer to limit islands by size,
condition natural!=coastline probably won't work correctly for/because
of relations.

--
Best regards,
Andrzej
___
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] Why do we render place=island polygons in the default style?

[Andrzej Popowski]

Hi Gerd,

I guess there could exist instances, where sea/lake doesn't include a 
hole and island can be overlaid over water. But these are errors easy to 
correct in OSM data. Other function for these objects is to add a label 
to an area.


In my styles I have removed islands from polygons but left them as a 
POI. From your suggestions I would prefer to limit islands by size, 
condition natural!=coastline probably won't work correctly for/because 
of relations.


--
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] Option to output polygons in size order

[Gerd Petermann]

I was curious and coded the sort. The result was a bit surprising, because the 
change of the order

has an effect on the shapes. This is of course not wanted, the reason is that 
we set some

flags on point objects which are shared by different shapes, depending on the 
order sometimes

a flag is set by a previously processed shape. I think this is a bug and should 
be corrected first.

I am not yet sure how, I think I tried to solve this problem before without 
success.


For the experts: I am talking about the "preserved" flag which tells the 
Douglas-Peucker filter and

other line simplification filters to keep a point. It is used for special nodes 
on roads and for shapes to

"preserve horizontal and vertical lines" which are on the boundary of the shape.

So, the flag is very important for routing and has an effect on shapes to avoid

holes (e.g. white areas in the sea).


I guess it would be better to use two different flags for the shapes and the 
routing nodes.



Gerd




Von: mkgmap-dev  im Auftrag von Felix 
Hartmann 
Gesendet: Sonntag, 24. Juli 2016 21:40:47
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Option to output polygons in size order

That is not really a good approach. Basecamp orders the polygons opposite to 
most gps devices. So it will still be broken.


There is however a proper way to do - but that would be much much more 
complicated: Create a list of polygons that may not overlap (in the 
style-file). Then if mkgmap finds that 2 of these polygons do overlap - mkgmap 
should cut out the smaller polygon shape from the bigger. Basically the result 
of that approach would mimic how a Mapnik map looks in this case. Still the 
real solution however would be to fix the underlying OSM data. I have no clue 
how code and time intensive the "mimic Mapnik" approach would be, but 
everything else won't really solve much.

On 24 July 2016 at 20:42, Gerd Petermann 
mailto:gpetermann_muenc...@hotmail.com>> wrote:

Hi Ticker,


with the current algo the order is either "unpredictable" or

the order in the input file (osm.pbf is typically sorted by id).

This depends on the --preserve-element-order

If I see this right this order will have an influence on the result

of the so-called shape merger which tries to combine shapes

with similar attributes.

I still don't understand why the size should matter, but it should

be easy to add a sort after the line

shapes = mergedShapes;

in MapBuilder.java


I don't have the time today, so try on your own or wait a little

for a patch .




Von: mkgmap-dev 
mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>>
 im Auftrag von Ticker Berkin 
mailto:rwb-mkg...@jagit.co.uk>>
Gesendet: Sonntag, 24. Juli 2016 20:23:41
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] Option to output polygons in size order

Hi Gerd

Looking at the meaning of the sub-division, this looks like just the
place to try and order the polygons by size! What governs the order
they appear in at the moment? The size should be the full size of the
individual polygon.

Concerning the new thread "Why do we render place=island polygons in
the default style", I have used "place=island & size_of() < 100" to
get around the major problem but it seemed a bit arbitrary, and when I
found other examples where, just sometimes, large polygons mask all
features within I thought there must be a more general solution

Ticker

On Sun, 2016-07-24 at 00:05 -0700, Gerd Petermann wrote:
> Hi Ticker,
>
> Ticker Berkin wrote
> > I'd understood and hoped that, for areas with the same level it
> > rendered areas in file order, and I see on my device it
> > overwriting,
> > sometimes woods with island, sometimes the other way around,
> > depending
> > on, I presumed, the input ordering. I see the exactly the same
> > overwriting effect zooming in or scrolling in any direction.
> >
> > What is the scale of the 'sub areas' you mention?
>
> I should have said sub division , and they have no specific scale.
> They are used to group nearby elements, and they have several limits
> like "not more than 255 points and not more than 255 lines in one sub
> div"
> For details see first the imgformat-1.0.pdf from Mechalas:
> http://sourceforge.net/projects/garmin-img/files/OldFiles/imgformat.p
> df/download
> Other sources:
> http://wiki.openstreetmap.org/wiki/OSM_Map_On_Garmin/IMG_File_Format
> (which has more links at the end)
>
> Reg. the British Islands polygon: If I got that right this is the
> very complex mp-relation
> https://www.openstreetmap.org/relation/6038068
> (don't use the link, the thing is too complex)
> It was added 2016-03-09 so maybe the problem is rather new and nobody
> noticed it. I think it makes no sense to render that polygon, the
> rules
> in the default style should be changed to check the
> area_size() for place=island so that large polygons are ignored.
> I'll try to find