Re: [mkgmap-dev] map boundary error

[Gerd Petermann]

Hi Mike,

I cannot reproduce your result with the command
java -jar mkgmap.jar -gmapi test.osm.
I assume you look at cached data. Did you press Ctrl+G 2 times?

Gerd


Von: mkgmap-dev  im Auftrag von Mike 
Baggaley 
Gesendet: Donnerstag, 18. Februar 2021 01:03
An: 'Development list for mkgmap'
Betreff: [mkgmap-dev] map boundary error

Hi all,

In creating a small test file I seem to have found an issue. The attached
OSM file has just 3 points and two ways form a right-angled triangle. In the
attached BaseCamp image, the blue line is the boundary of the map. Its
vertical lines contain the ways, but the horizontal lines do not. I can also
see that the road in the underlying base map enters into the blue rectangle,
suggesting that the blue line is not where the map boundary actually is. How
does this boundary line get created

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

Re: [mkgmap-dev] Pending changes

[Carlos Dávila]

HI all

I agree with Ticker default style is a good source of ideas for both new 
and experienced users (at least it is to me) and as such, more is 
better, but I also see Gerd's point about new users getting blocked by 
too many or complicated rules. I think comments about those complicated 
rules, as Ticker adds in some cases, may help circumvent that problem, 
or may be some kind of  tagging.


El 17/2/21 a las 11:02, Gerd Petermann escribió:

Hi Ticker,

I agree that the default style is a starting point and because of that I think "less 
is better":
1) The more stuff we put into the default style the less likely it becomes that 
a newbe will try to understand it. I think it is more likely that users will 
try to add a rule for something that they miss instead of working through 
hundredts of complicated rules to find out what can be (hast to be) removed 
without risking to loose anything important.
2) The screens of many (most?) Garmin devices are too small for lots of 
details, the details are simply confusing anyone who's not interested in OSM 
but just wants a routable map for free.

Gerd


Von: mkgmap-dev  im Auftrag von Ticker Berkin 

Gesendet: Mittwoch, 17. Februar 2021 10:47
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Pending changes

Hi Gerd

My views on this.

For most of mkgmap /resources/ (styles, typ-files, documentation,
roadNameConfig.txt, sample.cfg) you don't need to decide if the change
is good or bad, and, almost by definition, it is all cosmetic.

Change requests go through this forum for discussion. After any
refinements necessary, the changes can be incorporated into trunk. It
is very unlikely that this will cause Map generation will become
'broken'. Mostly, it seems, no one much cares because they use their
own styles, TYP files etc.

I view the default style (and the other resources) as a starting point
for new users and a source of ideas for existing users.

It is the ideal place to put rules/comments on any sort of issue that
can be addressed by a style. Generally, more is better; it is easy for
a new user to start with lots and gradually comment out elements they
don't want.

Whenever I notice something that could be improved on my maps, or a
good idea floating around the forum, I incorporated it into my files
and try it. Every now and again, I try to get what I consider
improvements into mkgmap. This isn't for my benefit but, I hope, other
people might benefit from it.

Similarly, mapnik.txt is a good place to put element translations (it
would be nice if we came up with a mechanism where this translation
effort could be shared by any TYP file).

The core/java code is a different matter and I'm very grateful for your
amazing work on "keeping it all together"

Ticker

On Fri, 2021-02-12 at 09:51 +, Gerd Petermann wrote:

Hi all,

I have no idea what to do with patches for default style or typ
files. I can decide if I like a patch when I understand what's wrong
with the unpatched version, but I don't want to spent my time on
cosmetic changes. I simply don't know how to decide if a patch is
good or bad unless someone has a good example that shows a problem
with the unpatched version (only one problem if possible).

I see two ways to handle this:
1) Steve gives Ticker and /or Joris the right to commit changes to
trunk or
2) Ticker and Joris create their own branch(es), either in the mkgmap
svn repo or somewhere else.

ciao,
Gerd



Von: mkgmap-dev  im Auftrag
von Ticker Berkin 
Gesendet: Freitag, 12. Februar 2021 10:37
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Pending changes

Hi Carlos

Some bridges are a bit of a strange case. There are a lot of areas
where I walk that are crossed by many small streams and no formal
paths, but, here and there, there are foot bridges over the streams.
These are normally mapped as [highway=path/footway, bridge=yes] and
mostly don't connect to anything, but sometime to another bridge or a
short section of unconnecting path.

I want to see these on the map, but the little bits of highway will
just cause a routing error if they are picked up as the start or end
of
a route; hence my changes.

The only problem I see is if the bridge/highway is connected to the
highway network at one end only and you want to generate a route with
the start or end your of your journey the other side of bridge, then
the routing algo might find another, closer start/end point.

I could change it to be just 'set_unconnected_type' but I considered
the benefits and frequency of fixing paired isolated highway bits
outweighed an incorrect start/end point, which can be overcome by
simply starting the journey in the sensible way and the device will
recalculate or looking at the end-point route and, seeing it is
stupid,
choosing a better end-point.

Ticker

On Thu, 2021-02-11 at 18:05 +0100, Carlos Dávila wrote:

Regarding your extra comment on #3, would it be real

Re: [mkgmap-dev] Documentation improvements for sea processing,

[Ticker Berkin]

Hi Mike & Gerd

No problems with this.

Concerning *-sea-sectors. My reading of the documentation implies
extend-sea-sectors and no-sea-sectors are alternatives. The
comprehension difficulty is because of the naming of 'extend-sea
-sectors', which are very different from the 'sea-sectors' that 'no-sea
-sectors' stops. 'sea-sectors' isn't a good name either because they
could be 'land-sectors'. Probably not worth thinking about this any
further.

Ticker

On Tue, 2021-02-16 at 20:23 +, Mike Baggaley wrote:
> Hi Gerd,
> 
> Please find attached a patch to improve the documentation of sea
> processing
> plus minor changes to --add-pois-to-lines.
> 
> I note that extend-sea-sectors says  "Adds a point so coastline
> reaches the
> nearest tile boundary. This implies no-sea-sectors". But no-sea
> -sectors
> disables the generation of sea sectors when the coastline fails to
> reach the
> tile's boundary, so I would have thought that extend-sea-sectors is
> an
> alternative action and would imply that no-sea-sectors is off.
> 
> Cheers,
> Mike
> ___
> 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] Pending changes

[Gerd Petermann]

Hi Ticker,

I agree that the default style is a starting point and because of that I think 
"less is better":
1) The more stuff we put into the default style the less likely it becomes that 
a newbe will try to understand it. I think it is more likely that users will 
try to add a rule for something that they miss instead of working through 
hundredts of complicated rules to find out what can be (hast to be) removed 
without risking to loose anything important.
2) The screens of many (most?) Garmin devices are too small for lots of 
details, the details are simply confusing anyone who's not interested in OSM 
but just wants a routable map for free.

Gerd


Von: mkgmap-dev  im Auftrag von Ticker 
Berkin 
Gesendet: Mittwoch, 17. Februar 2021 10:47
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Pending changes

Hi Gerd

My views on this.

For most of mkgmap /resources/ (styles, typ-files, documentation,
roadNameConfig.txt, sample.cfg) you don't need to decide if the change
is good or bad, and, almost by definition, it is all cosmetic.

Change requests go through this forum for discussion. After any
refinements necessary, the changes can be incorporated into trunk. It
is very unlikely that this will cause Map generation will become
'broken'. Mostly, it seems, no one much cares because they use their
own styles, TYP files etc.

I view the default style (and the other resources) as a starting point
for new users and a source of ideas for existing users.

It is the ideal place to put rules/comments on any sort of issue that
can be addressed by a style. Generally, more is better; it is easy for
a new user to start with lots and gradually comment out elements they
don't want.

Whenever I notice something that could be improved on my maps, or a
good idea floating around the forum, I incorporated it into my files
and try it. Every now and again, I try to get what I consider
improvements into mkgmap. This isn't for my benefit but, I hope, other
people might benefit from it.

Similarly, mapnik.txt is a good place to put element translations (it
would be nice if we came up with a mechanism where this translation
effort could be shared by any TYP file).

The core/java code is a different matter and I'm very grateful for your
amazing work on "keeping it all together"

Ticker

On Fri, 2021-02-12 at 09:51 +, Gerd Petermann wrote:
> Hi all,
>
> I have no idea what to do with patches for default style or typ
> files. I can decide if I like a patch when I understand what's wrong
> with the unpatched version, but I don't want to spent my time on
> cosmetic changes. I simply don't know how to decide if a patch is
> good or bad unless someone has a good example that shows a problem
> with the unpatched version (only one problem if possible).
>
> I see two ways to handle this:
> 1) Steve gives Ticker and /or Joris the right to commit changes to
> trunk or
> 2) Ticker and Joris create their own branch(es), either in the mkgmap
> svn repo or somewhere else.
>
> ciao,
> Gerd
>
>
> 
> Von: mkgmap-dev  im Auftrag
> von Ticker Berkin 
> Gesendet: Freitag, 12. Februar 2021 10:37
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Pending changes
>
> Hi Carlos
>
> Some bridges are a bit of a strange case. There are a lot of areas
> where I walk that are crossed by many small streams and no formal
> paths, but, here and there, there are foot bridges over the streams.
> These are normally mapped as [highway=path/footway, bridge=yes] and
> mostly don't connect to anything, but sometime to another bridge or a
> short section of unconnecting path.
>
> I want to see these on the map, but the little bits of highway will
> just cause a routing error if they are picked up as the start or end
> of
> a route; hence my changes.
>
> The only problem I see is if the bridge/highway is connected to the
> highway network at one end only and you want to generate a route with
> the start or end your of your journey the other side of bridge, then
> the routing algo might find another, closer start/end point.
>
> I could change it to be just 'set_unconnected_type' but I considered
> the benefits and frequency of fixing paired isolated highway bits
> outweighed an incorrect start/end point, which can be overcome by
> simply starting the journey in the sensible way and the device will
> recalculate or looking at the end-point route and, seeing it is
> stupid,
> choosing a better end-point.
>
> Ticker
>
> On Thu, 2021-02-11 at 18:05 +0100, Carlos Dávila wrote:
> > Regarding your extra comment on #3, would it be really the case for
> > bridges? What about any connected highway=* + bridge=yes?
> >
> > No objection for new additional changes
> >
> > El 11/2/21 a las 15:57, Ticker Berkin escribió:
> > > Hi all
> > >
> > > I've re-made this set of changes, along with a few improvements
> > > that
> > > I've gathered over the last 6 months. Following list numbering

Re: [mkgmap-dev] Pending changes

[Ticker Berkin]

Hi Gerd

My views on this.

For most of mkgmap /resources/ (styles, typ-files, documentation,
roadNameConfig.txt, sample.cfg) you don't need to decide if the change
is good or bad, and, almost by definition, it is all cosmetic.

Change requests go through this forum for discussion. After any
refinements necessary, the changes can be incorporated into trunk. It
is very unlikely that this will cause Map generation will become
'broken'. Mostly, it seems, no one much cares because they use their
own styles, TYP files etc.

I view the default style (and the other resources) as a starting point
for new users and a source of ideas for existing users.

It is the ideal place to put rules/comments on any sort of issue that
can be addressed by a style. Generally, more is better; it is easy for
a new user to start with lots and gradually comment out elements they
don't want.

Whenever I notice something that could be improved on my maps, or a
good idea floating around the forum, I incorporated it into my files
and try it. Every now and again, I try to get what I consider
improvements into mkgmap. This isn't for my benefit but, I hope, other
people might benefit from it.

Similarly, mapnik.txt is a good place to put element translations (it
would be nice if we came up with a mechanism where this translation
effort could be shared by any TYP file).

The core/java code is a different matter and I'm very grateful for your
amazing work on "keeping it all together"

Ticker

On Fri, 2021-02-12 at 09:51 +, Gerd Petermann wrote:
> Hi all,
> 
> I have no idea what to do with patches for default style or typ
> files. I can decide if I like a patch when I understand what's wrong
> with the unpatched version, but I don't want to spent my time on
> cosmetic changes. I simply don't know how to decide if a patch is
> good or bad unless someone has a good example that shows a problem
> with the unpatched version (only one problem if possible).
> 
> I see two ways to handle this:
> 1) Steve gives Ticker and /or Joris the right to commit changes to
> trunk or
> 2) Ticker and Joris create their own branch(es), either in the mkgmap
> svn repo or somewhere else.
> 
> ciao,
> Gerd
> 
> 
> 
> Von: mkgmap-dev  im Auftrag
> von Ticker Berkin 
> Gesendet: Freitag, 12. Februar 2021 10:37
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Pending changes
> 
> Hi Carlos
> 
> Some bridges are a bit of a strange case. There are a lot of areas
> where I walk that are crossed by many small streams and no formal
> paths, but, here and there, there are foot bridges over the streams.
> These are normally mapped as [highway=path/footway, bridge=yes] and
> mostly don't connect to anything, but sometime to another bridge or a
> short section of unconnecting path.
> 
> I want to see these on the map, but the little bits of highway will
> just cause a routing error if they are picked up as the start or end
> of
> a route; hence my changes.
> 
> The only problem I see is if the bridge/highway is connected to the
> highway network at one end only and you want to generate a route with
> the start or end your of your journey the other side of bridge, then
> the routing algo might find another, closer start/end point.
> 
> I could change it to be just 'set_unconnected_type' but I considered
> the benefits and frequency of fixing paired isolated highway bits
> outweighed an incorrect start/end point, which can be overcome by
> simply starting the journey in the sensible way and the device will
> recalculate or looking at the end-point route and, seeing it is
> stupid,
> choosing a better end-point.
> 
> Ticker
> 
> On Thu, 2021-02-11 at 18:05 +0100, Carlos Dávila wrote:
> > Regarding your extra comment on #3, would it be really the case for
> > bridges? What about any connected highway=* + bridge=yes?
> > 
> > No objection for new additional changes
> > 
> > El 11/2/21 a las 15:57, Ticker Berkin escribió:
> > > Hi all
> > > 
> > > I've re-made this set of changes, along with a few improvements
> > > that
> > > I've gathered over the last 6 months. Following list numbering is
> > > the
> > > same as original patch, but include some [extra] notes + new
> > > items
> > > at
> > > the end.
> > > 
> > > Relevant threads:
> > > http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2020q3/031375.html
> > > http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2020q3/031424.html
> > > 
> > > 1/ Sometimes charges for using a pedestrian highway are expressed
> > > as a
> > > fee rather than a toll, so pick this up in mkgmap:toll.
> > > 
> > > 2/ Show bridges using type 0x10107. With the mapnik addition,
> > > these
> > > look good for narrow highways, but might not show for wide
> > > representations like motorways.
> > > 
> > > 3/ Where it is likely that bits of highway might not be connected
> > > to
> > > the road/path system, use mkgmap:set_unconnected_type and
> > > mkgmap:set_semi_connected_type to stop the NET/NOD rather than
> >

Re: [mkgmap-dev] FYI Population specified on admin boundaries

[Joris Bo]

That's one to check 😊
This evening

Otherwise exclude if capital = 2 or something like that
Or in my case I use population from place=city if specified and else from 
admin-boundary





Met vriendelijke groeten,

Joris Bo
jori...@hotmail.com

-Oorspronkelijk bericht-
Van: mkgmap-dev  Namens Gerd Petermann
Verzonden: woensdag 17 februari 2021 08:58
Aan: Development list for mkgmap 
Onderwerp: Re: [mkgmap-dev] FYI Population specified on admin boundaries

Hi Joris,

doesn't that mean that the population of the whole country is used for the 
capital?

Gerd


Von: mkgmap-dev  im Auftrag von Joris 
Bo 
Gesendet: Mittwoch, 17. Februar 2021 08:12
An: Development list for mkgmap
Betreff: [mkgmap-dev] FYI Population specified on admin boundaries

Hi,

The French osm community decided to remove the population tag from cities and 
towns and add them the municipality admin-border instead.
Because of this tagging place=city can not be displayed at certain zoomlevels 
based on the population anymore.

I added this to the relation file to have large cities nicely popup early on 
lower zoomelvels again

type = boundary & boundary = administrative & population = * { apply 
role=admin_centre
  {
set population = '${population}';
  }
}

(or bettter:  you assign it here to a new tag “population_from_boundaries” and 
check both in the points style to avoid accidential overwrites, which I 
actually did)



Kind regards,

Joris Bo
jori...@hotmail.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