Re: [mkgmap-dev] Contour lines without elevation. What shoul mkgmap do?

[Greg Troxel]

Ticker Berkin  writes:

> Looking at the code, there shouldn't be any crash from mkgmap if a contour 
> line doesn't have an
> "ele" tag. I assume the Garmin device will just draw the appropriate line 
> without a label. This
> might be common where alternate contours are not given heights.
>
> So, no; I don't think you should add any checks.

I'm just barely reading list mail, but I agree with Ticker.  A contour
line without an elevation still makes sense, at least enough sense that
it shouldn't be rejected.

However, I don't really grasp Gerd's comment about elevations used for
routing.   Presumably that is in some newfangled Garmin device that
proceses a route with respect to contours?  If so, then I see how this
is really hard, choosing between:

  reject

  accept

  accept only if some flag is or isn't given, to be set depending on if
  one is building maps for routing/elevation devices
  
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] do people think mkgmap tests pass? (YES, clean pass on NetBSD)

[Greg Troxel]

Gerd Petermann  writes:

> sorry, last trunk version was r4839, not r4843. Tests are only executed for 
> trunk.

Following up in public:

  The problem was that on my system, I had no "java" in $PATH.  That's
  because pkgsrc has
-rwxr-xr-x  1 root  wheel  78800 Dec 13 17:39 
/usr/pkg/java/openjdk11/bin/java
-rwxr-xr-x  1 root  wheel   7712 Dec 13 18:20 
/usr/pkg/java/openjdk8/bin/java
  and you are supposed to add one of those.  I use the openjdk11 one
  when I run mkgmap, and I tend to like explicit config and not a
  choose-this-one symlink.

  I didn't notice because my build of ant is hard-wired to the openjd11
  version, and "ant dist" just workd.

  It might be nice for the tests to somehow notice that there is no
  java.  Or to ask ant what the path is?  But I can see why nobody wants
  to spend the time to do that...

  With java in path (a symlink from $HOME/bin/java to the openjdk11 one,
  with $HOME/bin in $PATH), I get a clean pass on NetBSD 9 with
  openjdk11 from pkgsrc-2021Q4.


Thanks for the hints.

Greg


signature.asc
Description: PGP signature
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] do people think mkgmap tests pass?

[Greg Troxel]

(After doing other things for a long time, I'm updating spliter, mkgmap,
and data prepartory to building new img files.)

I ran the mkgmap tests, and got some failures, 7 in args and 2 others.
I am using NetBSD, but that shouldn't matter.  Do people think "ant
test" gets a clean pass with the current svn?  If so I can send info
about the failing tests.

Thanks,
Greg


signature.asc
Description: PGP signature
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] default style lines enhancements

[Greg Troxel]

Ticker Berkin  writes:

> I was only going to join up paths that share a node with the edge of
> the car park - I wasn't going to do anything with paths that just go
> near the edge.

I think that's irregular tagging, and not likely to be interpreted the
way to intend by a number of routers, but I agree that this is a
reasonable interpretation for mkgmap of that tagging when it occurs,
which is the only thing that matters here.

> I disagree with the assertion that there are always parking isles and
> if these don't exist in the OSM data for a car park it has not been
> mapped correctly and should be fixed. This might be true in cities and
> out-of-town shopping areas but is rarely true in the UK for car parks
> in woods etc.

I didn't mean there were always clear aisles.  Just that you can
usually/almost-always draw a way that goes into the area that more or
less represents what you can do.
 
> Personally I disagree with the OSM requirement that footways from in/on
> the car park should be joined - this is just making up data that
> doesn't exist on the ground.

The real issue is that the OSM tagging scheme is not rich enough to
capture these nuances, and thus different people have different
preferred ways to approximate reality given the tagging scheme that
exists.  Clearly a difference of opinion among reasonable people --
thanks for the discusision.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Virtual paths

[Greg Troxel]

ael  writes:

>> Feel free; I don't expect that to go well.
>
> As far as I can see, the current discussion is just a special case of a
> general problem with OSM. Consider a park with grass cover with open
> access, or even just an area of, say open access moorland where it is
> possible & sensible to walk anywhere. As far as I know, all the OSM
> routers will fail to construct a route across such a place (presumably
> a straight line) in the absence of an explicit way of some sort.
>
> Adding a relation of the sort I suggested which would be verifiable and
> objective would solve the problem. Is there a better solution?

I didn't say your idea made no sense.  I said that I didn't expect the
discussion to go well :-)  But don't let my guess stop you.

I prefer soemthing like a polygon of type highway=path that covers the
free-routable space, to which regular ways are connected to.  Sort of
the same thing, but without adding relations in, and treating
free-routable areas as first-class items similar to line-routable ways.

> Of course, routers would not pick this up immmediately.
> As for mkgmap, I see that the Garmin firmware probably needs to support
> it somehow. Are we sure that Garmin doesn't have something that can
> interpolate between routing points? I guess that navit could probably
> be extended to do this sort of thing.

My impression is that people synthesize a bunch of diagonals when there
is an erea, for routers that don't do areas.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] default style lines enhancements

[Greg Troxel]

Ticker Berkin  writes:

>> And it will generate paths that may not actually exist, or might be
>> signed no trespassing.   Gerd has said that he doesn't want to
>> synthesize data that isn't in OSM, and I think this is wise.
>
> It is a public car park; you need to be able to walk to or from any
> point as that's where your car might be.

I thought we were talking about things that were outside of the car
park, with paths that sort of went to it, that people declined to attach
to the ways.

>> It is not about mkgmap.  It is pretty much all routers.  A path
>> represents "you can travel along this way with this mode and this
>> access".  That's exactly what is going on, at a simple level.  At a
>> more complicated level, you can claim that the parking lot is
>> pedestrian way, but that isn't really true.  It's really that the
>> thing that looks like a path comes to the edge of the path and there
>> is a way to continue walking onto pavement to get to the space
>> between aisles.
>
> I'm trying not to imagine anything that looks like a path, but I would
> consider it like a pedestrian area where you can walk anywhere
> reasonable within it.

I think we are not really communicating well and that could be my
fault.  I am seeing the larger OSM system, with tags that have meaning,
and routers that process those tags.   So the first goal is to have the
tags/objects in OSM actually represent reality.  Then to transform those
into the data that the routing engine uses.

In a car park, there are essentially always parking aisles, and that is
normally used for foot navigation only.  A carpark that is a big area
that doesn't have these is more or less not mapped correctly and should
be fixed.

If there really aren't any, then it needs some kind of tags that
everyone - not a special mkgmap custom - agrees that it represents a
pededstrian area.

> There isn't a method of representing this in a
> Garmin .img such that routing works in the expected way, and the next
> best thing, that solves the routing problems and that we can do with
> current technology, is to generate a foot routable navigation around
> the circumference. If this was to use an invisible line would you
> object less?

If you are only talking about making the Garmin routing follow the
semantics that everybody agrees is already expressed in OSM, then I
don't have any problem with it.  But in this discusison people are
talking about routing between paths that come close to a car park and
are not joined to the aisles as if that is correct.  That's really what
I think is wrong.

>> If there is a sidewalk around the lot, then map it.   And add ways to
>> get from sidewalk to the middle.
>
> I wouldn't want to add more than the minimum extra routes. The

I am talking about adding things that exist to OSM here.

> circumference is this minumum number. Routes to the middle are not the
> problem, but, as Gerd points out, having mkgmap decide where the middle
> is could be very wrong.

Do you think that there is a consensus in OSM that amenity=parking is by
definition a routable pedestrian area?  I find no trace of that notion
at  https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dparking
which shows parking aisles in the example.

> The debate about what is correct mapping is open. I think
> mkgmap/default style should provide the best routing given the existing
> data.

I think it's reasonable to process multiple tagging styles if each has
some adherents.  What I don't think ok is to magically join paths that
are near car parks to the car park.  I haven't heard anyone say that
this is a good representation and that routers should interpret these
gaps as routable.

>> I really do not understand the resistance to making the map data
>> represent what you can do on the ground.  It seems really obvious
>> that this is sensible, and that is the majority view within osm
>> tagging.
>
> I don't have any objection to this, but it doesn't work with what I
> often see on the ground, which is:
> 1/ an area where (sometimes free-format) parking is allowed.

If it's not free form the aisles should be drawn.  So we are now only
talking about areas that have no aisles.

> 2/ an access track that runs to the boundary that allows vehicles and
> links to the road system.

What I do for basically dirt parking lots with no lines, is to draw the
driveway going more or less in the middle basically to the other edge.
That is a proxy for being able to drive anywhere, a blend of what's
phsyically there and conveying semantics that are closer to correct than
having to stop at the edge.

When I map, I consider having a highway-type way share a node with
amenity=parking to be incorrect.

> 3/ multiple foot paths that start on the boundary of the car park.

So then either

  1) add an explicit pedestrian routable area in OSM

  2) join those paths to the central driveway, possibly adding more
  notional aisles

  3) add a footway around the perimeter, representing that you can walk
  

Re: [mkgmap-dev] default style lines enhancements

[Greg Troxel]

Ticker Berkin  writes:

> With the data as it stands, for sensible routes in the above situation
> and others as expressed in my earlier email, mkgmap needs to generate
> footways that join up all ways that lead into the car park with a
> footway. With the current technology this can be done with
> circumference footway and mkgmap:set_{semi_/un}connected_type provide a
> really good way of not doing this where the footway won't solve any
> routing issue and might cause routing island problems.

And it will generate paths that may not actually exist, or might be
signed no trespassing.   Gerd has said that he doesn't want to
synthesize data that isn't in OSM, and I think this is wise.

> I wouldn't object if OSM mappers joined all paths and the entrance
> road/parking aisles within the car park and maybe there should be a
> policy to do this and then there is no problem.

There is broad consensus that this is the right thing to do.  Editors
warn about "way end close to other way".

> However, there is a good argument that the correct OSM mapping is to
> show paths exactly as they are and not have to invent and add 'virtual'
> bits of footpath just to keep routing engines working sensibly because
> "mkgmap expects it like that".

It is not about mkgmap.  It is pretty much all routers.   A path
represents "you can travel along this way with this mode and this
access".  That's exactly what is going on, at a simple level.  At a more
complicated level, you can claim that the parking lot is  pedestrian
way, but that isn't really true.   It's really that the thing that looks
like a path comes to the edge of the path and there is a way to continue
walking onto pavement to get to the space between aisles.

If there is a sidewalk around the lot, then map it.   And add ways to
get from sidewalk to the middle.

> Other things that have been mentioned:
>
> - What about a path that runs up to or along the side of a car park but
> there is no access between them, eg an enclosed car park with a road
> along-side. I'd say that this is just incorrect mapping if the car park
> shares a node with the road but there is a barrier between.

It is almost always (alwyas?) incorrect to have a parking lot share a
node with a road.   That would imply that the parking lot beings on the
road centerline.

> - If starting within the car park, the route might tell you to walk
> around the edge rather that direct to the highway. Yes and no; it will
> plot a route to the closest edge and then to the best exit for the
> final destination; It should be obvious to the GPS user that they can
> just walk directly to the best exit. Without the change the only option
> you might get is onto the road network which could be entirely wrong.

with correct mapping, you usually get a sensible route along parking
aisles.


I really do not understand the resistance to making the map data
represent what you can do on the ground.  It seems really obvious that
this is sensible, and that is the majority view within osm tagging.

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

Re: [mkgmap-dev] Virtual paths

[Greg Troxel]

ael  writes:

> Not just mkgmap. It is a general problem. Maybe OSM should introduce
> a new relation "connected"? That is one or more ways and/or points could
> be members implying that it is possible to navigate (perhaps directly)
> between any of them. That would solve many of the problems for all
> routers. This idea needs expansion: a tag on the relation would specify
> the mode of transport, although I guess this would be mainly foot.
> Likewise, some sort of seasonal tag would be useful. But most of those
> already exist for ways, so I suppose those could be just be applied to
> the relation as well.

Right now we represent this with ways, and they have well-defined
semantics.  This seems comlicated and would need implementation in many
data consumers.

> Just musing out loud. If it seems sensible, maybe a proposal on the
> tagging list?

Feel free; I don't expect that to go well.


I do think, however, that mkgmap should simply interpret existing OSM
tagggin conventions, guided by analyzing how the broader set of routers
treat things.   (mkgmap+garmin is a router.)
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] default style lines enhancements

[Greg Troxel]

"Mike Baggaley"  writes:

> In the case I showed, I would probably have tagged it as you mention in view
> A as there is a parking aisle drawn. However, many small car parks do not

I left a note to check it next time I'm there.  My town is only a 10
mile march to the Old North Bridge :-)

> have parking aisles, and in that case I would not probably draw a footpath
> right across the car park and would go for view B. As one can normally walk
> anywhere on a car park, by definition you can also walk around the edge to
> any connected point, hence it seems reasonable to me to add the car park
> perimeter as foot routable. If you use Foot (OSRM) instead of Foot
> (GraphHopper) for OSM routing, it does take you around the edge of the car
> park.

Interesting that it's doing that.  It's odd, because it will only
transition from parking_aisle to perimeter where the driveway crosses on
the way out.  And representing the way that is the perimeter as foot
routable is also not how it really is.

> For vehicles, I would only expect a car park to be a start point or an
> end point, so it does not need to be routable. In the case of a fence, the

I find it useful to be able to navigate to a particular point in a
large lot.

> route around the edge is a routing artefact and you would actually walk
> across it, so if two paths join a car park you should be able to walk
> between them whether or not there is a fence around the edge.

I don't follow that.   Many lots have fences that humans cannot pass.

> Perhaps a
> better solution would be to join each point that stops at the edge of a car
> park together with a routable way. A new option to handle this?

I don't see why ways that go in/out should be joined at all to the area,
and would say it's wrong to do that.  At least unless the perimeter way
is represented as a routable area.

As for "small car parks", I always draw a way that is how you get in and
go betwween two places to park.  I don't have trouble knowing how to
draw this, given imagery and having been there.

Really, I don't see what's wrong with A: directly represent things that
can be done.   The only objection feels theoretical.

So far I am not at all convinced that mkgmap should do anything other
than straigthforwardly translate the map data.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] default style lines enhancements

[Greg Troxel]

"Mike Baggaley"  writes:

> I create foot routable (but not vehicle routable) ways around car parks in
> my style (I don't use the default style). This allows pedestrian routing
> around the car park in cases like
> https://www.openstreetmap.org/directions?engine=graphhopper_foot=42.45
> 938%2C-71.35133%3B42.45856%2C-71.35058 which is a few yards away from the
> previous example. It is common for footpaths to start at the edge of a car
> park and in my opinion it is incorrect to add to OSM a non-existent footpath
> across a car park purely for the purposes of routing.

That's really something to bring up on tagging.  As I see it there are
two views:

  A) one should continue the footpath in a way that represents how a
  person could walk to connect it to the parking aisles (that they also
  can walk on).  While there isn't something that is visibibly a
  footpath, there is in fact a place you can continue to walk from the
  edge of the lot to the parking aisle/driveway.

  B) Really there is a surface and one can walk anywhere there isn't a
  car parked, and thus the footpath should only represent the footpath
  and be joined to the edge.  Thus the carpark is really a routable
  pedestrian area.  This should either be the default or it should be
  tagged this way.

Two comments:

  I think A is the majority view in OSM by a wide margin.

  In B, you have to somehow deal with a fence around the lot, and be
  careful not to create routable ways that can't be traversed.  In this
  case, there is a fence on the SW side (not shown in OSM probably) but
  I think not on the NW side.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] default style lines enhancements

[Greg Troxel]

Gerd Petermann  writes:

> Hi all,
>
> I have two reasons why I don't like to create routable ways for objects which 
> are not meant to be routable ways:
> 1) Some mappers get it wrong and start to change OSM data to the worse 
> because "mkgmap expects it like that"

Didn't think of that but strongly agreed.

> 2) If a routable way is not mapped as such or not connected correctly in OSM 
> it should be fixed in OSM.

Completely agreed and that's what I meant to say.

> Besides I doubt that the additional ways help if you are on the car
> park and start to calculate a route. IIGTR It might tell you to walk
> around the car park instead of drawing a straight line to the next
> highway.

What I meant is that foot routes like this are found

  
https://www.openstreetmap.org/directions?engine=graphhopper_foot=42.46043%2C-71.35108%3B42.46162%2C-71.34935

but that's a case of correct OSM data, as it should be.

I think Ticker is saying that sometimes the footpath is joined to the
amenity=parking polygon, instead of the service road, and correct
routing does not magically jump over that gap.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] default style lines enhancements

[Greg Troxel]

Gerd Petermann  writes:

> Hi Ticker,
>
> reg. car parks: In what scenario do the additional routable ways help?
> Do you think of a car driver who stops there and tries to calculate a
> pedestrian route to a place which is not yet in sight?
>
> Gerd

All a good discussion about OSM, but I wonder what mkgmap should do.  If
a person can reasonably walk places, the ways should be connected and if
not it is a map bug.  Those bugs as Ticker describes are relatively
frequent.

As I see it the real question is whether mkgmap should make assumptions
that certain ways are connected when they aren't connected in the
database.  The default behavior would be to just process what's there,
with the result that routing is sometimes not so great, in that it
leaves out things you actually can do.  But the most interesting such
things can' be guessed.

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

Re: [mkgmap-dev] Road speed through urban areas

[Greg Troxel]

mural...@montevideo.com.uy writes:

> Be careful, if you drop the class for traffic_signals it brokes long
> distance routing, because (at least in South America) a lot of
> primarys and trunks have traffic_signals.

I don't think your situation is unusual, but I have never driven south
of Key West :-)

In the US, Interstates ("motorway") never have siganls.

Primaries often do, in more urban areas, and in unpopulated areas rarely
do.  Some US highways near me are posted 30 mph (~50 km/h) and have
lights every 400m, and lots of businesses.   primary in the road
hierarchy - the one I am talking about is US 20 and it goes from Boston
all the way to the west coast - and the biggest road around, arguably
the 4th most important E-W road in massachusetts.  But still  in eastern
mass it is slow to drive on.

trunk, more or less, is supposed to be things that are sort of a bit
like motorways but aren't quite.  around me, those are divided, very few
if any businesses on them, occasional (every mile or so?)  intersections
that aren't grade-spearated.  Typically you can achive 50 mph (80 km/h)
on them and maybe average 40mph/65km/h over longish intervals.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Road speed through urban areas

[Greg Troxel]

mural...@montevideo.com.uy writes:

> Be careful, if you drop the class for traffic_signals it brokes long
> distance routing, because (at least in South America) a lot of
> primarys and trunks have traffic_signals.
>
> I have been using the a map with a style that applies a -1 penalty for
> road_speed in case of traffic signals, and it works well in cities and
> in long distance routing, and it improves the estimated times.

What I meant is

  compute using a richer routing algorithm how long traversal will take

  compute what length to have a reduced class, or what length/reduction
  combos, to match the richer alogrithm

  make sure to do this in both directions

  demote for some class/distance, or perhaps the whole length for short
  segements between adjoining traffic_signals


essentially

  construct a network with road_class set so that routing on that
  network as garmin does, produces the same outcome as using a
  signals-aware routing algorithm

which I realize is a tall order
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Road speed through urban areas

[Greg Troxel]

Ticker Berkin  writes:

>   mkgmap:country=XXX & mkgmap:admin_level8=* {set
> mkgmap:road-speed=-1}
> However, I haven't looked at the
> bounds/admin_level topic in any detail.

In Massachusetts, *everywhere* is within an admin_level=8.  One of these
is Boston, which is very crowded, and there are towns with 300 people
and probably more cows than that, over probably 40 km^2.   So being in
an admin_level=8 does not imply that you can't drive the posted limit.

This "admin8 is slow" rule also fails verifiability as much as
maxspeed:practical.

> Accurate road speeds must be a good idea, giving better estimates of
> journey time and, in some cases, faster routes. Even if
> maxspeed:practical isn't in the default style, I'd have it in mine if
> there was a chance of useful data for it to pick up.

To me it's clear that the right thing is to 1) tag major roads in cities
with maxspeed:practical, if you can't drive at the posted speed and 2)
respect maxspeed:practical.  Just because the wiki crowd doesn't like is
not that important; OSM has a culture of arguing about tagging in a
vacuum rather than in the context of how data consumers use it, and this
culture is broken.

> To indicate slowed speeds at lights/crossings, need --link-pois-to-way
> and, in "points", something like:
>   highway=traffic_signals | highway=crossing {set mkgmap:road-speed=1}
> This, if necessary, chops the road up and applies the specified speed
> to a short section around the point.

That sounds promising.   OsmAnd I am pretty sure adds time for
traversing lights, but it isn't trying to program someone else's routing
engine.

I suppose the traffic_signasl (and stop) could also drop the class for
longer segments if it basically works out the same.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Road speed through urban areas

[Greg Troxel]

Fernando Trebien  writes:

> Would mapping boundary=urban [1] help solve the problem of assigning a
> slower estimated speed to ways within dense urban areas in routing
> apps such as mkgmap? [2][3] It looks like an elegant solution to this
> problem that would not have the same issues with verifiability that
> maxspeed:practical has. It is currently common only in France (see an
> example in Rennes [4]) and there is official data available in my area
> that could be imported into OSM. [5]

I don't see why drawing a line that encloses the area where you think
maxspeed:practical is low is any more verifiable.  You are tagging about
an area where people drive slower than the speed limits, I think.  So
it's really the same thing.

Also, maxspeed:practical is easy to verify.  Drive on the road 10 times
and see what the average speed you actually went is.  I have lots  of
commuting data and someday, I will process it and see what the
distributions look like.


If there really are speed limits, then by all means tag them.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Road speed through urban areas

[Greg Troxel]

Ticker Berkin  writes:

> Yes, this is what I mean, more or less. I don't know what the OSM
> tagging policy is on applying maxspeed tags to every road, but mkgmap
> applies its own limits based on highway type to everything except
> motorway, and this patch now does motorways as well.

OSM policy is more or less that every road should have its actual
maxspeed tagged, and that while it is reasonable to infer defaults from
road type when it isn't, that's a workaround for lack of data.

Which is what you are doing, so that's 100% fine in my view.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Road speed through urban areas

[Greg Troxel]

Ticker Berkin  writes:

> It also needs something at the end to limit motorways for most
> countries:
>
> highway=motorway & mkgmap:road-speed-max!=* & mkgmap:country!=DEU
> {set mkgmap:road-speed-max=6}

Do you mean

  Except Germany, most/all countries have speed limits on motorways, but
  some of them don't have explicit tags in OSM.  While this is a bug in
  the data and should be fixed, mkgmap ought to do something sensible

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

Re: [mkgmap-dev] Road speed through urban areas

[Greg Troxel]

Fernando Trebien  writes:

> maxspeed:practical=* & maxspeed=* & maxspeed:practical < $maxspeed {
> set maxspeed='${maxspeed:practical}' }

Not really bearing on your particular problem, but I don't think
checking with < makes sense. If maxspeed:practical is set, it represents
the speed that people actually can reasonably drive.

It can be that this practical, socially acceptable speed is higher than
the limit.  There is a road around me that is built almost like an
interstate but has an inexplicable 45 mph speed limit.  Traffic normally
flows at 70 mph.  Anyone going 45 mph is really in the way to the point
of being dangerous, and people might call the police to report an
impaired driver.

So if practical is higher, use it.  Which means "if practical is set,
use it".
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Road speed through urban areas

[Greg Troxel]

> The mkgmap default style doesn't understand maxspeed:practical.

Thanks.  I was unclear on this.

I would suggest that mkgmap should in the default style use the first
one of these that is defined:

  maxspeed:practical
  maxspeed:advisory (yellow sign, in the US, not a requirement, but advice)
  maxspeed (legal limit)

I am unclear on if advisory is used in non-US places.  Here we often
e.g.  have yellow "45" signs on curves on roads with "55" limit (white)
signs, and on exit ramps (slip roads in en_GB, *_link in osm).
Sometimes the advisory speeds are sensible, some times they are way too
low and occasionally they are too high.  A great case for using
practical to fix them.


I would expect this to be quite necessary in rural UK and IE, as it
seems there is a tradition of 100 km/h or 60 mph outside town centers,
but at times roads often narrower/twisty such that at least I didn't
think it wise.

(The US doesn't do this so much; very rarely is the legal limit unsafe.
There are dirt roads where :practical should be used, though.)
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Road speed through urban areas

[Greg Troxel]

Fernando Trebien  writes:

> I've downloaded the source code [1] and read through the default
> styles in ./trunk/resources/styles/default/ . If I understood
> correctly, it sets road_speed=3 (60km/h [2]) for highway=secondary and
> road_speed=2 (40km/h [2]) for highway=tertiary. Those are reasonable
> in rural areas, but too fast in urban areas, where average speeds
> usually drop by around half of their real speed limit.I also found
> rules for handling the speed limit in maxspeed=*, but it seems like
> his issue would persist even when this tag is provided in map data.

The basic problem is that if you are using default speeds baseed on osm
road type, that's a clue that speed limits rae missing.

The next problem is that there is maxspeed and maxspeed:practical, and
if you cannot drive at the speed limit usually, you should

  set maxspeed:practical

  check that if maxspeed:practical exists, mkgmpa uses it as the speed
  limit

> I think it might make sense to write a custom style [3] setting
> road_speed=2 for highway=secondary and road_speed=1 (20km/h [2]) for
> highway=tertiary. Perhaps this would then break some rural routes.

That may make a map that works in one area, but it just moves the
problem.

> I've found that Garmin supports traffic data, [5] but I'm unsure if
> this works with maps converted using mkgmap, as I don't own any Garmin
> device. Do you know?

I have never seen a claim that it works.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] How to make a scale-dependent TYP style?

[Greg Troxel]

Ticker Berkin  writes:

> For both, apart from the above, I much prefer their default rendering
> rather than, say, {distribution}/examples/typ-files/mapnik.txt which
> also slows down the devices to an almost unusable speed. 

Is your preferred approach part of mkgmap now?  I didn't find it
alongside the mapnik typ, and I think it would be useful to share, as an
example, or for use.  I have been using mkgmap for a very long time and
concur that less is better.  I did use to use cferrero's typfile and
style, which was mostly about adding stoplights and some other things
not usually shown.   I'd like to see towers/masts as well, survey
markers, and various other things that I'm not sure render without typ.

(I admit to being a little distant from what's going on as I mainly use
OsmAnd, but I carry my etrex 30 as well, so I have two functioning
devices in the woods.)

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

[mkgmap-dev] best practices for parcel data?

[Greg Troxel]

(Yes, I know parcel data does not belong in OSM.  I am not putting it
in, and not proposing to do so.)

I am making maps for a my etrex 30 with a Geofabrik extract of
Massachusetts in pbf, and files that I converted from MassGIS "parcels"
data, which is basically shapefiles with tax lots and also easements.

This results in polygons with tags variously as

  boundary=parcel
  boundary=easement

I have the following diff, which results in a contour that is pretty
visible and a very thin blue line that is "intermittent stream".  The
lot lines show as "contour line" and don't say depth on the Etrex 30.

I am not firmly attached to this; I'm looking for a reasonable way to
have lot lines and easements shown so that I can understand them.

I suspect I could pick some not-really-used codepoints and put in TYP
file content for them

Other than TYP, does anyone have suggestions for a good way to do this?
Is adding this to the default style sensible, because OSM doctrine is to
merge parcel data when rendering?  Or am I unusual and me carrying a
patch is better?

As always, thanks to everyone who has worked on mkgmap.  My MassGIS
shapefile to OSM conversion was some effort, but the mkgmap part was
easy.

Greg


Index: resources/styles/default/lines
===
--- resources/styles/default/lines  (revision 4451)
+++ resources/styles/default/lines  (working copy)
@@ -248,6 +248,10 @@
 boundary=administrative [0x1c resolution 22]
 boundary=national [0x1e resolution 17]
 boundary=political [0x1c resolution 19]
+# 0x23 is depth countour - thin.  Wacky but useful.  0x1c is too heavy
+boundary=parcel [0x23 resolution 20]
+# wild guess
+boundary=easement [0x26 resolution 20]
 
 barrier=wall | barrier=fence | barrier=hedge | barrier=ditch {add 
name='${barrier|subst:"_=> "}'} [0x17 resolution 24]
 

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

Re: [mkgmap-dev] change handling of railway=abandoned

[Greg Troxel]

I think part of the problem is that railway=abandonded is not a
statement either way about

  whether it is reasonably physically traversable on foot

  whether there is any right of access

so I guess I don't see why a way with railway=abandonded and no highway
tags should be presumed routable in the first place.

I guess the real issue is that garmin thinks it is?



(Also, for US people, note that OSM's definition of abandoned is
different from the US definition.  The US definition is a legal thing,
and some rails that are US-abandoned have tracks present.  Nothing to do
in mkgmap, but if you are a US railfan and not an OSM expert, you'll
assume wrong.)
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Shouldn't both options --gmapi and --nsis imply --tdbfile?

[Greg Troxel]

Gerd Petermann  writes:

> I never understood why adding option --gmapsupp suppresses the
> creation of the pc index file(s). Is it really only because the
> current implementation requires more memory?

I don't understand either, and it feels like a bug.

I have long been in favor of having the defaults make the map that a
user of a reasonably modern device (oregon, etrex 30, etc.) would want,
if they understood the options.  It seems like index/route should be on
by default, and there can be --no-index for devices where that causes
trouble.

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

[mkgmap-dev] line types for unpaved roads (was default style improvements)

[Greg Troxel]

Ticker Berkin  writes:

> On Sun, 2019-01-06 at 08:50 -0500, Greg Troxel wrote:
>
> This request is slightly confused by 2 issues:
>
> 1/ The mkgmap/garmin attribute mkgmap:unpaved which is used by the
> routing option "avoid unpaved" on some (older?) Garmin devices to avoid
> unpaved roads.
>
> 2/ The line type 0x0a = "Unpaved Road" being used by the default style
> for highway=track, highway=unsurfaced and railway=abandoned

> Is the existing setting in the default style of mkgmap:unpaved (based
> on tags surface, mtb:scale, tracktype, sac_scale) adequate, or are
> there other tags/values that need to considered? 

I have no reason to think anything is wrong there.

Is there another mechanism for avoidance on other devices?  That could
interact with the line type choice, if those avoid line 0x0a only, and
e.g. not extended line types we want to use to show other unpaved ways.

> Are you thinking of having another line type? The default style has
> used all but 1 of the non-extended road types that show on newer
> devices without a typ-file specification; and I was thinking of using
> the last one (0x0b) as the Hint portion of a *_link instead of 0x06,
> which is also used for highway=minor & highway=unclassified

Yes, basically.

(highway=minor sounds like an osm bug; that could also get a comment in
the style that it's accomodating strange tagging.)


Upleveling as I am wont to do from excessive formal computer science
training:

I think we're at the point where the richness of the OSM data model
exceeds that of the basic Garmin data model.   I see two approaches:

  project OSM onto Garmin, losing detail

  use new line types and a TYP file

There is merit in each approach; perhaps there should be a no-typ
default style and then a style that has within it a typ sourcefile that
is used by default with the style, developed together with the style.

> Which highway types should be changed, eg unclassified, minor,
> tertiary, *_link, ... motorway? Should this new road type have the same
> [road_class road_speed resolution] attributes as the existing highway
> that it is replacing or can it just have a single fixed set of these
> attributes?

Ideally, we'd have

  a separate visual presentation for unpaved versions of
motorway/primary/secondary/tertiary/unclassified/residential/service
plus all their link variants
  (I agree that unpaved motorway feels wrong, and arguably it can be
  ignored because if there is one (Alaska still?) everybody knows
  already and in those places checking "avoid unpaved roads" isn't useful.)

  from a routing point of view, road class and road_speed should be set
  on these in the same manner as if paved, presumably class from osm way
  type, and speed from tags (or maybe defaults).
  (Maybe maybe there should be a default maxpeed:practical to unsurfaced
  ways if there is no explicit maxspeed tag, but that's tricky business
  of second-guessing defaults to make routing work better.)

  avoid unpaved knows about these on all devices

  I don't see why resolution should be different than if paved; way type
  encodes hierarchy.

  track, path, railroads (active/abandoned/razed) all look different.
  track has less visual weight than unpaved residential.

  in particular, a highway=secondary or highway=tertiary with
  surface=unpaved should show up on the map quite differently than
  track.

I think these goals lead to using unused extended line types and
controlling their appearance with the TYP file.  I think this approach
means that TYP file is not optional and needs to be in sync with the
style.

> Given answers to these questions, it can be done, but again, in some
> future change

Sure -- I was not meaning to suggest that your present changes are
problematic because they don't do everything I have ever wanted!
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] default style improvements

[Greg Troxel]

Bernhard Hiller  writes:

> I often travel on bike in "nowhere land", where hotels and restaurants
> are rare. So I think it is good to show both PoIs if a hotel contains
> a restaurant. Of course, it would be more relevant to know how other
> users of OSM Garmin maps think about this topic (I use my own style,
> so the changes to the default style are not relevant for me).

There are two issues; one is display, and the other is search.  I think
ti's pretty important that "show me cafes and restaurants nearby" find
hotel restaurants (that are open to non-guests).  I don't think it's
quite as important that they both show up.  But when zoomed all the way
in, it would be nice.  Plus, mappers often put the hotel POI on the
building and a separate restuarant POI where the restaurant is.

> A different point I'd like to suggest is a new line type for unpaved
> highways (which are not tracks). Unpaved public highways may be not
> very common in Europe, but they are rather normal in other areas of
> the world.
> The fact that they are rendered like paved highways makes many mappers
> think that it is useless to add this tag - and the little use of the
> surface tag in turn makes map makers think that it does not
> matter... Clouds of dust caused by other vehicles on that road or
> getting stuck in a muddy quagmire are not great user experiences.
> Treating them differently for routing purposes is a good step, but
> that is not such visible to many users.

Agreed that unpaved public roads should have a different symbol.  (Even
where I am, in Massachusetts, US, they have a significant existence.)

(I think the real reason they don't exist in the UK is that it's too wet
and they would always be muddy.  I drove on some roads there that are so
minor that almost certainly would not have been paved in the US.   And
this UK non-existence of unpaved  real roads has led to some distortion
of their representation in OSM.)

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

Re: [mkgmap-dev] default style improvements

[Greg Troxel]

Ticker Berkin  writes:

> I know that the OSM definition says square should have area=yes, but I
> find a vast number where there is no area tag and they seem to be
> square/piazza, eg
>
> https://www.openstreetmap.org/relation/5174171
>
> With Italy data from July 2018, I get about 5000 highway=pedestrian
> polygons without an area tag, and, from a small sample, about 1 in 3
> look like piazza.
>
> The only effect is that a polygon is generated, it doesn't effect
> routes. I prefer to see the possible square rendered.

I see this as part of a larger issue: when the OSM data is wrong, but
it's possible to figure out what it should have been, should those
errors be fixed up in map generation?

A compromise might be to explicitly note the workaround in the style
file, rather than making it seem like the style is correctly
interpreting the data.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] How can I force the inners of a boundary relation to display?

[Greg Troxel]

Dave Swarthout  writes:

> I do use a fill. It isn't a solid color but a small letter "R" to stand for
> Reserve. That does show me where the inners are in a fashion but I would
> like to experiment with getting them to display with some sort of a line.

Certainly that makes sense and my comments were stronger than they
should have been.

I wonder if the issue is with things being too large to fit in some sort
of tile, or if this happens even for small objects.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] How can I force the inners of a boundary relation to display?

[Greg Troxel]

Dave Swarthout  writes:

> I've been adding large Alaskan National Wildlife Refuges to OSM. The
> boundaries weren't displaying so I added a directive in my relations file
> modeled after the administrative boundary code in the default style that
> adds a name to protected areas like so:
>
> (type=boundary | type=multipolygon) & boundary=protected_area & name=*
> { apply
>   {
> set mkgmap:boundary_name='$(mkgmap:boundary_name)/${name}' | '${name}';
>   }
> }
>
> Then in my lines file I included a line style defined as:
> boundary=nature_reserve
> | boundary=protected_area [0x10e12 resolution 19].
>
> This works well but the lines bounding the inner areas of these relations
> do not render. How can I make them display?

Not what you asked, but I reject the notion that because the tag is
"boundary=protected_area" that what should be rendered is a line on the
boundary, rather than an area.  I view this tag as denoting something
about the area within the polygon -- basically landuse=conservation
and/or leisure=nature_reserve.

So I would treat these boundary tags as being about the area and use a
green fill, and not focus so much on the boundary proper.

I realize that mine is not a universally-held view :-)
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Missing addr:place addresses

[Greg Troxel]

Gerd Petermann  writes:

> this is for sure confusing. I think the problem is in the data flow.

thanks - I am starting to understand.

> Current implementation works like this:
> 1) Single OSM ways are passed to the style rules
> 2) The style can create 0, 1 or more routable lines (=roads) and 0 or more 
> other lines for this single OSM way.
> 3) The next step is to fix "wrong angles" so that zig-zagging is reduced
> 4) Now ways that represent roads are merged when they have similar attributes
> 5) The ways representing roads are then converted to a different data 
> structure called MapRoad.
> 6) Finally the housenumber code tries to add address information to those 
> MapRoad instances. There are several concepts in OSM
> to represent adresses, the normal one is addr:housenumber + addr:street, 
> another one is the combination
> of addr:housenumber + addr:place. The latter is typically used in rural areas 
> where you have a
> few buildings with the same addr:place value. In reality, those buildings 
> often have a service way but it is rarely mapped.
> If it is mapped mkgmap tries to add the address information to that service 
> road. This also means that it has to add a label to an
> unnamed road, else address search would not work. Without a nearby service 
> road it adds the address information to the next best road.
> If that road has a name that doesn't match the name given with addr:place 
> mkgmap adds another label for the place name.
> The problem starts when such a "next best road" passes several places with 
> different names since roads can only have 4 labels.

I would say that the basic problem is that the way garmin format
represents addresses does not match the way the world is, and does not
match the OSM data model.  Adding street names to streets that do not
have names seems to me to risk unintended confusion.

(Note that I live in an area where there is a legal requirement for
addresses to be housenumber/road-name, driven by both the post office
and emergency services response.  In Massachusettts, US, we are talking
about importing government address data, and one of the quality checks
on individiual addresses is "is there a road in OSM with that name,
which is nearby enough".  But that's the plan in our area, legally, and
I realize other places are different.)

Wtih addr:housenumber and addr:place, I would expect that often there is
no road with the same value as addr:place.   I would think that if you
talked to the local inhabitants they would say that this is correct.
Even if a place of "Fooville" had a "Fooville Road", it probably doesn't
match exactly.  (Around me, roads are often named for the town they go
to, but it's town "Concord" and road "Concord Road".)

Perhaps the Garmin data structure reflects the US notions of addresses
being #/road-name.

Overall, I think your idea of having road objects with some
not-really-there attributes (zero length, if it works), and putting the
addressing information on them is the right approach, in cases when
there is not an actual road with a missing name.  That lets the address
search use the data structure, even though there is in fact no road with
that name, and it seems to cause the least amount of confusion.
Probably searching for that name as a road name will turn up things, but
that may not be avoidable.

I would suggest that if the road is zero length, then there's no worry
about road class and speed; if it appears as a service road with a 20
km/hr speed limit for the 0m, then that doesn't seem harmful in terms of
misleading any human or machine data consumers.  But there might be a
way to not have the road turn in up road name search.  And, if the route
ends near the address, it probably doesn't matter if it includes the
0-length way, as long as the way is found in address search.

I hope this is helpful, and thanks for your work over many years.
Being able to get OSM data on my garmin units is part of what made me
start mapping.


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

Re: [mkgmap-dev] Missing addr:place addresses

[Greg Troxel]

Lorenzo Mastrogiacomi  writes:

> If I understand correctly I would say yes.
> unclassified roads should be tagged with name=* in osm if they have a
> name and should not take names from nearby roads.

I am really not following what's going on.

Most unclassified roads will have a name and some might not.

Some service roads (and tracks) will have names and most will not.

Addresses on building/nodes will have a variety of address components.
Typically, an address with a given addr:street will be located
reasonably close to some highway way with that same name.  But not
necessarily; the world is not designed by computer scientists :-)

I"m not really clear on addr:place; that sounds like a name from the
settlment hierarchy rather than the administrative hierarchy, and which
is used in addressing will depend on local customs.

I think this question is about putting address ranges on named highway
ways, because the garmin format doesn't represent individual addresses.
I can certainly see merging ways that are the same in tags that mkgmap
considers important (ignoring width changes, etc.).  But I don't
understand merging ways with names and ways without names.

A further complexity is address points far from the road in question,
and perhaps closer to some other road (e.g. a 1 km driveway).  There, I
could see a process of figuring out that the address point and the named
way are related by the service road and thus the address point should
perhaps be considered to be on the named way where the service road
connects.

I admit to never having taken the time to make addressing work in my
garmin maps so far; I mostly use them for hiking and I use OSMAnd for
car navigation.


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

Re: [mkgmap-dev] New branch for default typ file

[Greg Troxel]

Ben Konrath  writes:

> I realize this is a bit off-topic on this thread but I'm curious to know
> your process for combing non-OSM data with splitter. I was just starting a

I don't think it's off topic at all.

> project to add some non-OSM data to my maps but I thought the only way to
> do this was with osmosis, combining a generated change file with the real
> data. Is your process documented somewhere? If not, do you mind sharing it
> here?

I have generated a file "lots.osm" which has parcel data as polygons
with boundary=parcel tags, and just call splitter with
"us-northeast-latest.osm.pbf" and "lots.osm".

My lots.osm file has negative numbers for ids.  I remember using some
python code to read shapefiles and write the osm file, but I no longer
remember the details.  There is nothing odd about the file, other than
using negative ids.

With 64-bit ids, perhaps I should be picking some other private range
that isn't negative.  But I bet it doesn't matter as long as they are
unique.

I've been doing this for years with no problems.


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

Re: [mkgmap-dev] New branch for default typ file

[Greg Troxel]

Ticker Berkin  writes:

(I'm a long-term mkgamp user, sometimes contributor, mostly lurking
lately.)

> I don't think having:
>
> BRANCH: default-typ
>
> makes sense because I don't think there will ever be a single, ideal
> file. So better to accept now that it will be a collection of files,
> and, as nothing exists at the moment, they might as well go in 'trunk'.

As I see it, branches are useful for protecting trunk from changes that
are in-progress or controversial.  Adding some typ sources doesn't seem
to rise to that.  But if so, then surely we'd have a branch until it's
reviewed, and then merge it and delete the branch.  I'm unclear on if
that's the choice, or if there is some other suggestion that I don't
understand.

> I don't know what the best visual effect should be either, but, having
> tried a complex example I found somewhere, the raw Garmin device
> rendering (with just a _drawOrder section in the TYP file) looked much,
> much better.

Having a bunch of examples sounds good.  I would like to head to a
default typ file that is integrated with the default style, so that
rendering is more or less aligned with mapnik, but perhaps a bit more
detailed at high zoom.

I used to use cferrero's style/typ and really liked it, but with mkgmap
improvements over the years it was no longer usable without more clue
than I had.   The big thing over no-typ was showing traffic lights.



Semi-related, I am carrying a diff to render "boundary=parcel"; I
include state parcel boundary data with osm data in splitter.  I have no
idea how many others want this, but given that parcel data is not in
OSM, merging while mapbuilding (or a separate transparent parcel map)
seems pretty useful.  What I'm doing is not really ok, but I'm just
mentioning the concept.

# 0x23 is depth countour - thin.  Wacky but useful.  0x1c is too heavy
boundary=parcel [0x23 resolution 20]
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] New branch for default typ file

[Greg Troxel]

Ticker Berkin  writes:

> I suspect there will be a few TYP files for different usages.

perhaps, but as I understand it there can be a lot of
include/not-include in styles, so I see TYP files being different as a
high-level difference, within which there can be maps built for
different reasons.   And I would hope there would be fewer TYP files,
just because things are confusing enough.

> I propose that they should be handled like the styles, where they are
> gathered in a directory resources/TYPs and the build process copies
> then to dist/examples/TYPs
>
> I don't think a new branch is necessary, as there is nothing in the
> system at the moment.
>
> I'd like to submit my most basic TYPfile and attach the file and patch.
> This, along with option --order-by-decreasing-area, has been adequate
> for me for a few years (but I have problems with my new Etrex 30x not
> showing some line types)

That sounds fine to me.  I would hope that the TYP file is not actually
checked in, but the source code that the mkgmap TYP compiler users, so
it can be edited easily.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] new option --add-boundary-nodes-at-admin-boundaries

[Greg Troxel]

Gerd Petermann  writes:

> my understanding is this:
> The additional nodes (only) help when you create multiple maps. For example,
> if you have a script that creates a map for a given geofabrik extract by 
> executing splitter and mkgmap.
> If you feed that script 1st with Maine and 2nd with New Hampshire you get two 
> different maps
> with overlapping tiles.
> If you use osmconvert to merge the two extracts before using the script there 
> are no overlapping tiles and
> thus there is no need for the additional nodes.

Thanks - that matches my understanding too.  What I meant is that long
long ago I was using multiple state extracts, and I think feeding them
into splitter together, and I found that I could not make cross-state
routes.  But that may work now because of geofrabrik itself being sure
to have matching nodes in adjacent extracts.

Based on that trouble, when us-northeast came out, I started using it,
since it was only 600 MB or so for the img, which was small enough not
to be a hassle.

I was thinking that it might be reasonable to process each US state to
produce an img, separately, and then to just load the ones you want.  So
people may want to try that out with
  --add-boundary-nodes-at-admin-boundaries=4
in the US.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] new option --add-boundary-nodes-at-admin-boundaries

[Greg Troxel]

Gerd Petermann  writes:

> please try r4213 in the country-border branch, I think it is ready for merge 
> into trunk:
> http://www.mkgmap.org.uk/download/mkgmap.html
>
> I hope this description is clear enough, please suggest improvements / 
> corrections:

My usual plea about mkgmap: the options that are recommended should be
on by default, instead of expecting the user to enable 20 different
options after understanding them.

If you mean to add the code with it off, and after testing that it
doesn't cause harm, make it default, then I withdraw my complaint :-)
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Why is mkgmap the option --country-name=name

[Greg Troxel]

Eugeny_B  writes:

> Why is mkgmap the option --country-name=name and --country-abbr=abbreviation,
> that it can not take the country name from --bounds=directory|zipfile

My experience, not really figured out, is that objects inherit the given
country if they do not match anything from bounds (and probably, only if
they are not explicitly tagged).

I have not yet figured out how many objects get no country, when
building from the geofabrik US Northeast extract.  I also have not
figured out what happens to those objects in terms of the indexes when
there is no default country.


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

Re: [mkgmap-dev] addresses in the United States

[Greg Troxel]

Following up on my address troubles:

I removed the country and region arguments.

I updated splitter and mkgmap to the latest (head) and rebuilt, and now
I am getting country choices of United States, Canada (presumably from
overlap at the extract edge), and "Country" (perhap from an area not in
either boundary).

Choosing United States, I'm offered towns/cities from the region, but
they are shown with the state now, not county.

In "city" search (vs addresses), I can find hamlets/villages which are
denote non-administrative named places, and this seems good.

So things seem almost entirely right.   I wonder if there should be a
warning option for addresses not inside a boundary, when using
location-autofill=is_in, or if those points should just not get added to
the index (and perhaps counted in an output message).


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

[mkgmap-dev] addresses in the United States

[Greg Troxel]

(I have been using mkgmap for a really long time, and have been a little
out of touch with it the last few years mostly due to using OsmAnd on my
phone, although I still build maps for my Etrex 30 for hiking.)

I built osm.img from Geofabrik's us-northeast.  On my Nuvi 50, I find
that I can find Massachusetts towns, but not towns in Rhode Island.  I
realized this was due to my not really understanding the address options
and using them wrong/not-at-all.  So I read the docs about precompiled
bounds and sea and added those, using the files from mkgmap.org.uk, and
rebuilt.  Hence I am not asking about my earlier not-right builds.

With the new osm.img, in address search, there is only "United States"
vs "Canada", and no per-state option.  Towns can be found in any of the
states in my source file, but they show with their counties only, not
the state.  If you pick the right town/county combination, streets are
found, and I believe housenumbers, when they exist in OSM.  This is
harder than you might think because we basically reuse town names and
county names from England separately in each State :-)

When building, I first use splitter, and I think I have not had any
splitter issues in many years.  Then I run mkgmap (details at end).

Note that in addition to us-northeast.obf, I also add a file which has
parcel boundaries in my town convreted to OSM format, and I have a style
rule that shows them as marine depth contours.  This has been working
for many years.  My style diff in lines is:
  +# 0x23 is depth countour - thin.  Wacky but useful.  0x1c is too heavy
  +boundary=parcel [0x23 resolution 20]
I don't think this matters, but I don't feel right leaving out the info.

For no good reason, my recent build was done with
  r3997 | gerd | 2017-09-26 03:49:38 -0400 (Tue, 26 Sep 2017) | 1 line
and I am going to update and try again, without the --region-* arguments.
Other than the parcel style change my only other local changes are doc
fixes that I need to check and submit some day.

My questions are:

  1. I have leftover --region-* arguments in my script, and I'm
 wondering if that's the issue.  Should I remove those?  Does that
 explain the state/county confusion?

  2. I would expect the admin boundaries for state, county and town to
 be used from the bounds file, to fill in those address elements for
 roads, as well as for explicitly tagged addresses if they only have
 housenumber/street.  Is that right?   Fairly clearly the town and
 county boundaries are being used correctly.

 (Actually also county boundaries for counties that do not have
 admin_level=6 because of overzealous nonlocals who think it's
 helpful to remove those for counties that don't legally have a
 separate government, even though nobody who uses the map has any
 idea about this fine point and everyone refers to counties as a
 real thing.  But counties are showing up, so that's not the
 problem.)

  3. To make the best map possible for normal people to use navigating
 with a nuvi, without crossing into custom styles, should I be doing
 something different?

  4. Given the goal in (3), should I be crossing into a custom style?

  5. In addition to the admin hierarchy, which is what everyone thinks
 of in terms of addresses, there are also a lot of place names (as
 nodes) in OSM, with tags like village and hamlet.  These are names
 for where there were concentrations of house long ago, and many are
 in use today.  People use them as in "I live near Tracey's Corner"
 but would never put "Tracey's Corner" as a component of their
 address.  by using is_in, I think I'm not using those, and I don't
 think this is related to my problem anyway.

java \
-enableassertions \
-Xmx3072m \
-jar splitter.jar \
--output=pbf \
--max-nodes=${MAXNODES} \
--keep-complete=no \
$INPUT \

java \
-enableassertions \
-Xmx6144m \
-jar mkgmap.jar \
--max-jobs \
--latin1 \
--description="OSM_gdt" \
--country-abbr="US" \
--country-name="United States" \
--region-abbr="MA" \
--region-name="Massachusetts" \
--family-id=1500 \
--family-name="OSM_gdt_family" \
--product-id=13 \
--series-name="OSM_gdt_series" \
--area-name="OSM_gdt_area" \
--draw-priority=60 \
--overview-mapname=6324 \
--tdbfile \
--precomp-sea=sea.zip \
--reduce-point-density=4 \
--reduce-point-density-polygon=8 \
--merge-lines \
--route \
--check-roundabouts \
--check-roundabout-flares \
--remove-short-arcs \
--adjust-turn-headings \
--report-similar-arcs \
--report-dead-ends=2 \
--add-pois-to-areas \
--check-styles \
--index \
--bounds=bounds.zip \
--housenumbers \
--location-autofill=is_in \
-c template.args \
--gmapsupp


Thanks,
Greg (osm user gdt)


signature.asc
Description: PGP signature

Re: [mkgmap-dev] unpaved roads

[Greg Troxel]

Gerd Petermann  writes:

> as you said we have to live with the limitations of the Garmin img
> format and the routing algo.  My understanding is that the default
> style should produce reasonable results for correct input data.

Yes, that's of course a good general principle.

> If I got you right you'd like to have some user interface (maybe
> sliders in a GUI) to express your preferences of different road types
> or surface types and that should be used to "fine tune" the values for
> road_speed, road_class, and the unpaved flag so that one doesn't have
> to understand all the complex rules?

I should say that I am unclear  enough about what would be ideal that I
don't want to be on record as making a specific software request.  But
yes, some general framework for expressing how the user wants road costs
to work, which leads to those changes, sounds like a good idea.

It may be that the reasonable default rules we are evolving are good
enough, so that more complicated schemes are not worth their cost.

Anyway, thanks for listening.


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

Re: [mkgmap-dev] unpaved roads

[Greg Troxel]

Gerd Petermann  writes:

> 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.

[I know I'm late to replying; I left the thread unread until I had time
to read it and think a bit.]

One question is what should "unpaved" mean.  That probably depends on
car vs bicycle, and it seems the real issue is that the Garmin format
isn't expressive enough to allow routing to decide later what it wants
to use.  Thus we are having to map each road to a paved yes/no, road
class, and speed class.

Another way to look at this is to ask why we are representing unpaved
roads, and what the routing policy is we are trying to achieve by that.
In my case, for car, generally what I want is to not use rough roads
(dirt, and even cobblestone) unless it's more or less necessary, which
I'd define as being the only way or saving lots of time, even if I drive
10 km/h on the rough road.

So I would suggest that we think of the Garmin unpaved flag as a "this
is a road I want to avoid, as opposed to a road I don't want to avoid"
bit, and not be so fixated on what paved means.  That may mean different
people build images with different rules.

Then, I would think about what an optimal route is, and how to get the
Garmin unit to compute one when it thinks it is doing shortest time and
avoiding unpaved.  So I would use the unpaved flag for roads that you
really don't want to use, even if they save time, and use lower speed
classes for roads that you have a mild preference for avoiding.

Of course, I am not really sure how this would work.  And I realize it's
trickier with bicycle, where you care about pleasant/safe and time is
not so much the point. But I think the only way is to try to map some
utility function into inverse speed and let the Garmin unit try to
minimize time, since apparently there's no way to compute other utility
functions directly.  So basically if you'd rather ride 5 miles on road A
than 1 mile on road B, as an alternative to get someplace, set A's speed
to 5x B's speed, and then min time will do the right thing, even if you
get bad time estimates.




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

Re: [mkgmap-dev] Distinction between smooth paved/rough paved/unpaved streets

[Greg Troxel]

As I understand it, the garmin format has only a single unpaved bit.  So
the mkgmap style basically has to map all surface types to either paved
(no tags) or unpaved (mkgmap:unpaved=1).

Another approach is to set speeds on roads that you wish to avoid, using
the speed as a weight.

I am curious what you actually want.  Assume an area with a 50 km/h
speed limit.  Then on a paved street one can go 50.  What speeds would
you set for cobblestone/sett and dirt so that the min-time route would
be the behavior you desire and why?I am not trying to give you a
hard time - I have been thinking about how to make routes that people
want for a long time, but not done much about it and this is another
interesting case.




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

Re: [mkgmap-dev] Adding the gmapi format.

[Greg Troxel]

Andrzej Popowski  writes:

> gmapi is used to install maps on MacOS. This extension is associated
> with Garmin programs, but I think gmap works the same. I don't know
> any use for gmapi on Windows, all you need on Windows is gmap folder.

I thought gmapi was normal, but I'm using basecamp on OS X to view
mkgmap-generated maps.  I put them in GMAPI, and

  $ ls -lR GMAPI

  total 0
  drwxr-xr-x+ 3 gdt  staff  102 Nov 20 12:01 OSM_gdt_series.gmapi

  GMAPI/OSM_gdt_series.gmapi:
  total 0
  drwxr-xr-x+ 7 gdt  staff  238 Nov 20 12:01 OSM_gdt_series.gmap

  GMAPI/OSM_gdt_series.gmapi/OSM_gdt_series.gmap:
  total 36
  -rw-r--r--+   1 gdt  staff   1322 Nov 20 12:01 6324.mdx
  drwxr-xr-x+   4 gdt  staff136 Nov 20 12:01 6324_mdr
  -rw-r--r--+   1 gdt  staff  26883 Nov 20 12:01 CFMaster.TYP
  -rw-r--r--+   1 gdt  staff552 Nov 20 12:01 Info.xml
  drwxr-xr-x+ 113 gdt  staff   3842 Nov 20 12:01 OSMTiles

I have always done "open GMAPI/OSM_gdt_series.gmapi" to start
mapmanager, but "open GMAPI/OSM_gdt_series.gmapi/OSM_gdt_series.gmap"
worked also.

So I don't think the outer container is needed.  Plus, this is easy to
add back if we figure out later that it's useful.  But I don't think its
presence hurts anything.

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

Re: [mkgmap-dev] Feature Request: mkgmap able to create gmap archive (BaseCamp)

[Greg Troxel]

Steve Ratcliffe  writes:

>> I'm wondering if it would be possible that mkgmap is able to
>> create/convert maps also in the gmap (gmapi) format used for BaseCamp on
>> Windows and Macintosh.
>
> Yes, this seems a reasonable thing to do.

I would like to see this too.  I run mkgmap on a mac, and want to have
both a big .img to load directly and also gmapi format to load into
basecamp.

> In the mkgmap code base there is a python program called
> gmapi-builder.py in the scripts directory.
>
> See also https://bitbucket.org/berteun/gmapibuilder/overview
> and http://wiki.openstreetmap.org/wiki/Gmapibuilder.
>
> This is a converter, but should work on all platforms with python
> installed, or could be made to do so...
> The first step is to verify that it works; then it should
> be easy enough to implement within mkgmap itself.

For what it's worth, I have been using gmapibuilder with mkgmap for a
very long time.  The mod time on my gmapibuilder.py file is December
2009.  I have had essentially zero trouble.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Distinction between smooth paved/rough paved/unpaved streets

[Greg Troxel]

Alexandre Folle de Menezes <afmlis...@terra.com.br> writes:

> On 01/12/2016 11:35, Greg Troxel wrote:
>> Carlos Dávila <cdavi...@orangecorreo.es> writes:
>>
>>> You can use something like this:
>>> highway=residential & (surface=concrete | surface=asphalt) [0x06
>>> road_class=X road_speed=Y resolution 22]
>>> highway=residential & (surface=sett | surface=paving_stones) [0x06
>>> road_class=A road_speed=B resolution 22]
>>> highway=residential [0x06 road_class=0 road_speed=2 resolution 22]
>>> Try different X and Y values to fit your needs.
>>
>> I would also suggest to set a special speed for surface=sett/etc. and to
>> use the regular paved speed for roads that are either not marked with a
>> surface tag or have some unknown value.  Basically, assume it's ok
>> unless there is a specific tag you understand.

> Yes, my plan was to add "paved" with the first group.  How do I add
> unmarked roads?

There is a syntax for not having a tag, but I would also have that as
the last thing.

So I would just do:

highway=residential & (surface=sett | surface=paving_stones) [0x06  
road_class=0 road_speed=X resolution 22]
highway=residential [0x06 road_class=0 road_speed=2 resolution 22]

and let things without a surface tag end up in the same category as
surface=asphalt.  Around me, most roads are asphalt and they rarely have
paved or surface tags.

Plus, there is processing for unpaved, and those rules result in
different values.  I'm not suggesting to change that.


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

Re: [mkgmap-dev] Distinction between smooth paved/rough paved/unpaved streets

[Greg Troxel]

Carlos Dávila  writes:

> You can use something like this:
> highway=residential & (surface=concrete | surface=asphalt) [0x06
> road_class=X road_speed=Y resolution 22]
> highway=residential & (surface=sett | surface=paving_stones) [0x06
> road_class=A road_speed=B resolution 22]
> highway=residential [0x06 road_class=0 road_speed=2 resolution 22]
> Try different X and Y values to fit your needs.


I would also suggest to set a special speed for surface=sett/etc. and to
use the regular paved speed for roads that are either not marked with a
surface tag or have some unknown value.  Basically, assume it's ok
unless there is a specific tag you understand.


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

Re: [mkgmap-dev] eTrex Vista

[Greg Troxel]

Jakob Mühldorfer  writes:

> sorry to ask this here, but I have a device question.
> Does someone here use an ancient eTrex Vista (non c, non cx, non Hcx),
> and knows if mkgmap files can be transferred via serial port and be
> used on it?
> All information is highly welcome

I'm not sure if I'm being duplicative because my German is not so good
(understatement!).

I know of two ways to transfer maps to a serial port garmin.  There is a
program "sendmap" floating around, and I have only seen a binary for
Linux.   Also, Garmin's mapinstall/mapmanager/basecamp (or roadtrip) can
do this, installing subsets of the map after you have loaded it.

For the second way, on a mac

  use gmapibuilder to make a GMAPI format from the img

  open the gmapi to use mapinstall

  open manmanager and click a lot until you figure it out

for sendmap:

  find a sendmap binary

  make an IMG

  run sendmail with the img and the serial port

  figure out the limit on IMG size

  repeat

however, keep in mind that an etrex vista, not HC, probably has a very
small area for maps.  I had a GPS V that could do maps but not really
load a big area (20 MB?), and that was with the proprietary data that
had only roads and POIs, not what OSM has.

So I do not think you are going to end up being happy


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

Re: [mkgmap-dev] render landuse=orchard

[Greg Troxel]

Greg Troxel <g...@ir.bbn.com> writes:

> railway=abandoned {add access=no} [0x0a road_class=0 road_speed=1 resolution 
> 22]

Also, this is much harder because of implicit tagging in two ways:

  access tags have defaults depending on other tags.   highway=path has
  a default of yes for foot/bicycle/horse and no for car.

  access=no I think implies not only car=no but also foot=no.

So, I would be inclined to try to set the unset tags based on types.
Basically (I am bad at style rules; hopefully this makes senes):

  highway=path & !foot= {add foot=yes}

  access=$1 & ~foot= {add foot=$1}

so that then a non-set access tag can be no, and railway=abandoned will
default to all access being no unless tagged.

I realize the above is half baked but I hope it is helpful anyway


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

Re: [mkgmap-dev] render landuse=orchard

[Greg Troxel]

Gerd Petermann  writes:

> If I got that right we should change the style rules in at least two places.
>
> If a way with railway=abandoned is member of a route relation with
> e.g. route=hiking we want the way to be routable for pedestrians, see
> e.g https://www.openstreetmap.org/way/56214377 which is part of
> relation https://www.openstreetmap.org/relation/1735816
>
> If we simply change the lines style to
>
> railway=abandoned {add access=no} [0x0a road_class=0 road_speed=1 resolution 
> 22]

> this way would not be usable for pedestrians.

True.  I think this is a general problem, when a way (or its relations -
I don't see relation vs direct tags as being super important for this
dicussion) has multiple tags, then mkgmap has to decide which of them
controls the garmin line code.  That said, I tealize that relations are
not necessarily handled the same, so that may complicated the
implementation.  But I don't think it affects the intended semantics.

> So we need an additional rule in relations to store the info that a
> way is member of a route relation, and we should evaluate that
> information somewhere in lines or inc\access.

It's not really about being a route relation.  The thing that matters is
that the railway=abandoned is also either highway=path or
highway=cycleway, or something else that if it did not have
railway=abandoned would be routable.  Usually that sort of physical tag
belongs on the way, not on a relation which would assign ref tags or
route tags to a collection of ways.

So I think if someone has a route relation over a bunch of ways that are
railway=abandoned and the route is about cycling and not an old
railroad, and there are no highway=path/cycleway/footway/track tags,
then it is correct to have a nonroutable line type and the tagging
should be updated to reflect the access.

What mkgmap has to do is just to evaluate the rules that assign
path/footway/cycleway/track tags before the railway=abandoned tags.

Or a fancier style could have two types, routable and a non-routable,
that both render as old railroad, and use the routable one for path/rail
and the nonroutable one for just rail.

> I assume that this should also be done for highway=*, but I am not
> sure how to handle conflicts, for example a way may have
> "highway=footway and no explicit bicycle tag" and be a part of a
> route=bicycle relation. Does that mean that the relation is wrong or
> that the way should be accessible for bicycles?

Two thoughts here:

1) The tag

  highway=footway

is equivalent to

  highway=path foot=designated

and neither says yes or no for bicycle.  The default for path (and thus
for highway=footway) is bicycle=yes.   So that should be the same.

2) "route=bicycle" denotes a bicycle route, which is a logical
association of some bicycle route ref with all the underlying ways.  It
really does not say anything about access.  There could be a bicycle
route for which many or all of the ways are access=private.

Overall I would recommend to let the route=bicycle relation simply
associate the refs (and shields), and to let access tags be about
access, and not try to do anything fancier.

Does this make sense?


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

Re: [mkgmap-dev] render landuse=orchard

[Greg Troxel]

Gerd Petermann  writes:

> @Greg: please note that the way is not only rendered, it is also
> routable. I think that is what Ticker doesn't like.

That's fair enough.  railway=abandoned probably should not be routed.

> @Minko: I have no experience with
> railway=abandoned.  I read about cycle routes which follow the old
> railway tracks, but I would expect that the ways building those routes
> have tags like highway=* or cycleway=* and therefore I often wondered
> why we make those ways routable.

Yes, around me there are some railway=abandoned where there are some
sort of tracks/evidence, and these are not themselves cycle paths.
Sometimes you can walk on them, and sometimes it would be really tough
to get through (we have a fairly wet climate and the weeds/bushes/trees
grow very quickly).

Sometimes, the tracks are removed and brush is cleared, and then tagging
to show the useful way (path, or track if a 4WD truck could pass) is
appropriate.  Sometimes, a seriously fancy paved cycle path is put in,
and then it's highway=cycleway.

So the notion that railway=abandoned does not imply that a way is usable
is a good one, and that something tagged highway=path or
highway=cycleway is given the corresponding routable type is good.

I am into old railroads, so I want to see them on the map as I travel
around, which caused my reaction.   But I don't want to route on them,
especially if you can't actually travel.

All of this leads to wanting a displayed non-routable way.



Sort of related, wanting new symbols leads to wanting a standard TYP
file.  (I have been sort of disconnected from mkgmap for a while, but am
still using it.)  I know there is support for compiling a TYP file, but
it would be really nice if there were a standard (includedin mkgmap
sources) file that had features for things like
railway=disused/abandoned/razed and also stoplights/etc.  Sort of a
general-purpose standard rendering.

(Sorry if that's already there and I should be paying more attention!)

Greg


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

Re: [mkgmap-dev] render landuse=orchard

[Greg Troxel]

Minko  writes:

> @Ticker:
> Please do not remove railway=abandoned, it is often used as cycleway trail 
> after the railways have been demolished.
> The tags railway=dismantled, railway=razed, railway=historic and
> railway=obliterated are used to tag a former railway, where mostly all
> evidence of the line has been removed.

+1.  If there is phsyical evidence, it's a valid map feature and should
be rendered somehow.



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

Re: [mkgmap-dev] incorporating available data sets into osm

[Greg Troxel]

987654...@use.startmail.com writes:

> I am new to osm and am not sure if this is the appropriate forum in
> which to ask this question so if it is not, I would appreciate any
> direction with respect to the best place to post it.

Gerd is quite right about the import process and list.  I would advise
joining the list and lurking for a month or two before posting, so that
you can calibrate yourself on the reactions.

> I am working in the Northeastern US.  Many streams are missing from the
> map.  I found a site

Note that one thing you can do is to merge other data and OSM and then
run mkgmap on it.  I am 99% sure that if you do not distribute the
merged data, you will be ok with respect to OSM's ODbL.

Doing this has been on my todo list for a while, for both hydro and
addressing.

> " Data Distribution Agreement
>
> I. Description of Data to be Provided.
>
> The data provided herein are distributed subject to the
> following conditions and restrictions:
>
> SUBJECT DATA LAYERS
>
> For all data contained herein, NJDEP makes no
> representations of any kind, including, but not limited to, the
> warranties of merchantability or fitness for a particular use,
> nor are any such warranties to be implied with respect to the
> digital data layers furnished hereunder.  NJDEP assumes no
> responsibility to maintain them in any manner or form.
>
> II.Terms of Agreement
>
> 1. Digital data received from the NJDEP are to be used
> solely for internal purposes in the conduct of daily affairs.

This is inconsistent with the Contributor Terms.   So this data cannot
be added to OSM.

>  *   3. Digital data received from the NJDEP may not be
> reproduced or redistributed for use by anyone without first
> obtaining written permission from the NJDEP.  This clause is not
> intended to restrict distribution of printed mapped information
> produced from the digital data.*

Again this is inconsistent.

> 4. Any maps, publications, reports, or other documents
> produced as a result of this project that utilize NJDEP digital
> data will credit the NJDEP's Geographic Information System (GIS)
> as the source of the data with the following credit/disclaimer:
>
> "This (map/publication/report) was developed using New
> Jersey Department of Environmental Protection Geographic
> Information System digital data, but this secondary product has
> not been verified by NJDEP and is not state-authorized."

This doesn't fit; OSM can attribute on wiki pages or changeset comments,
but cannot possibly demand (and does not, more importantly) that any map
have thousands of such disclaimers.

> 5.Users shall require any independent contractor, hired
> to undertake work that will utilize digital data obtained from
> the NJDEP, to agree not to use, reproduce, or redistribute NJDEP
> GIS data for any purpose other than the specified contractual
> work.  All copies of NJDEP GIS data utilized by an independent
> contractor will be required to be returned to the original user
> at the close of such contractual work.

wow

> Users hereby agree to abide by the use and reproduction
> conditions specified above and agree to hold any independent
> contractor to the same terms.  By using data provided herein,
> the user acknowledges that terms and conditions have been read
> and that the user is bound by these criteria."

I would suggest talking to the NJDEP  and see if you can find a
sympathetic person, and if they would be willing to offer a license
compatible with the Contributor Terms.   You can point them at MassGIS,
which has terms that are basically Public Domain with attribution
requested.   But their terms are very far away from that, so I don't
expect rapid progress.

You might look at USGS data, and the National Hydrography Dataset,
which, being a work of the US government, is actually public domain.

  http://nhd.usgs.gov/


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

Re: [mkgmap-dev] don't route through highway=construction

[Greg Troxel]

I agree that 'highway=construction' should be omitted from routing.
That to me indicates "they are building a road but it is not usable".
If the default style routes over that, it's just a bug and should be
fixed.


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

Re: [mkgmap-dev] don't route through highway=construction

[Greg Troxel]

Gerd Petermann  writes:

> The clause setaccess=no will not work if the way has a tag like vehicle=yes 
> or foot=yes,
> as it only sets the mkgmap:* tags. 

That's an interesting point.

In the US, it's almost 100% true that a highway=construction is also
more or less marked as "no trespassing".  So
  highway=construction foot=yes
sounds funny to me.  Highways under construction are scary places with
heavy equipment and large amounts of dirt are moved around all the
time.  I would expect to get maybe almost arrested if walking in one, or at
least told to get out and stay out.

But if there were a highway project that was unusable by cars and people
really were allowed to walk on it, then that could make sense, and I
could see it being added to routing with car=no and foot=yes.

(If the road is usable, then it isn't highway=construction.)

Are there really situations like that (as opposed to a path alongside
the construction)?I am asking because if it's just that
'highway=construction is completely ignored for routing' is good enough,
it's probably easier.



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

Re: [mkgmap-dev] don't route through highway=construction

[Greg Troxel]

Richard Welty <rwe...@averillpark.net> writes:

> On 10/13/15 10:34 AM, Greg Troxel wrote:
>> I agree that 'highway=construction' should be omitted from routing.
>> That to me indicates "they are building a road but it is not usable".
>> If the default style routes over that, it's just a bug and should be
>> fixed.

> last time i looked highway=construction didn't imply access at all,
> leaving it to the mapper to set access= appropriately.

It doesn't explicitly, but there's a strong implication that
highway=construction is for unusable roads - because construction=minor
is for usable roads with construction activity.  Quoting:

  For minor road-works (where the road in question remains open), use
  construction=minor (and don't use highway=construction, but leave it at
  its default value).

> this makes sense, because sometimes construction is impassible and
> sometimes it's not.

repairs and resurfacing etc. are generally passable and that's what
construction=minoris for.  A new road that has been proposed and is now
being built is essentially never passable.  Or once it is, it's time to
retag it has highway=secondary or whatever and add construction=minor.

> unfortunately, the wiki doesn't really explain this and what mappers
> and data consumers are actually doing seems variable and inconsistent.

True, it's a mess like all things wiki :-)



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

Re: [mkgmap-dev] Should we exclued bridges from housenumber processing?

[Greg Troxel]

Gerd Petermann gpetermann_muenc...@hotmail.com writes:

 Mario Batschke suggested in a private mail to use
 highway=*  bridge=yes {set mkgmap:numbers=false}
 in the finalize section for lines so that addresses are not
 assigned to bridges. 

 I think this is a good idea.

 He also suggested to exclude tunnels, but I see quite a lot
 cases where this doesn't improve the address search, e.g.
 for shops in underground stations.

I don't see why an address shouldn't be valid just because it's on a
road that happens to be a bridge.  It would be good to get pointers to
the situations where people think this proposed rule makes sense, and we
can then see if we think there are tagging errors.



pgpZkMRDa0Mg5.pgp
Description: PGP signature
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] superfluous country specific rules in inc/address?

[Greg Troxel]

Steve Sgalowski steve.sgalow...@gmail.com writes:

 mkgmap:country  admin level 5

 then mkgmap:state admin level 6
 mkgmap:region admin level 7
 postcode sdmin level 8
 suburb  level 9, 10

My quick reaction is that which admin_level corresponds to which parts
of an address varies by region.  In my part of the US, state is level4,
city/town is level8, and that's really all there is in address.
Whether a (legal) city/town is suburb, city, town, village,
etc. is based on size and relationship to larger entities.

Around me only two cities have admin_level 10 boundaries.  One calls
them neighborhoods or villages, not suburbs.  Sometimes they show up in
postal addresses.

So really I wonder if this means that the address component rules should
be encoded on the boundary, something like addresses within this
polygon inherit name_component_foo=bar.

I am leaning to having addresses have everything (in the US) below state
explicit, to avoid this.




pgpZ6iRkTY4dl.pgp
Description: PGP signature
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] RFC: naming unnamed roads

[Greg Troxel]

Marko Mäkelä marko.mak...@iki.fi writes:

 That's an interesting point.  In the US, around me, there really
 aren't such assumptions.  Instead, a lot (area of land that can be
 bought and sold as a unit) has an address, generally taken from a
 public or private way that borders the lot.

 I see. I have some knowledge of the administrative system of
 properties in Finland. I do not think that street names play any role
 there. A property may have been assigned an arbitrary name by its
 owner, but it always has a registration number that uniquely
 identifies the lot. If the lot is split, I guess that all parts of it
 will get a longer registration number (adding some suffix to the
 original number).  Nowadays, the fully qualified registration number
 should start with the NUTS (Nomenclature of Territorial Units for
 Statistics) prefix of the municipality.

 Streets may be renamed or renumbered (seldom, but possible when lots
 of properties have been split and new houses built, for example). This
 would not affect the registration numbers of the properties. BTW, I
 don't think that the registration numbers will or should be put to the
 OSM database. They are only relevant when buying or selling
 properties.  It should suffice to have the administrative boundaries
 of the suburbs or villages.

We also have parcel numbers which are more or less similar (town, zoning
map sheet name, parcel number, and suffix on subdivision).  We also do
not use them in addressing and generally no one has an idea unless they
are dealing with applications under zoning rules.   So I think until we
have an example of addresses being based on these, mkgmap can ignore them.

 In Finland, when the same street goes through multiple municipalities,
 it usually changes names at the border. This is unlike what I saw in
 the US: El Camino Real in California would be called that for the
 whole way, and you would have to pay attention when crossing borders,
 because there could be multiple identical house numbers, maybe some
 tens of miles apart. Sure, in every country, you will have common
 street names such as Main Street or equivalent in every town, but
 those would typically not be part of a major route. However, this
 should not be a problem for the Garmin format. El Camino Real would be
 split to sections at municipality borders, and each section would be
 assigned its own house number data.

The US is highly variable and both styles exist.  Around me, road names
often change at the town border, and if they don't the addresses usually
reset.  For extra confusion, roads are named for the town they go to, so
you can be on Lexington Road in Waltham and after crossing be on Waltham
Road in Lexington.

Agreed that this doesn't cause mkgmap/garmin problems.


pgpmB0MrHZ2vR.pgp
Description: PGP signature
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] RFC: naming unnamed roads

[Greg Troxel]

Marko Mäkelä marko.mak...@iki.fi writes:

 The general assumption would seem to be that the street names attached
 to house addresses belong to roads that are reachable by car, or that
 each residence is reachable by car. Maybe in some rare case there is
 some access restriction on the road associated with the address, such
 as access=destination. There could be named cycleways or footways
 between the road and the address node, but no named public roads with
 a different name, unless there is an error in the map data.

That's an interesting point.  In the US, around me, there really aren't
such assumptions.  Instead, a lot (area of land that can be bought and
sold as a unit) has an address, generally taken from a public or private
way that borders the lot.  Some lots don't really have addresses that
are useful, if they aren't near roads.  Then a building on the lot,
certainly if there's only one, inherits the address of the lot.  ANd if
there's going to be a building, then the lot needs to have a proper
address (for emergency services purposes) and one will get assigned.  So
it definitely tends to work out 99.99% of the time that a building's
address is near the named road, and that one drives to that road to
access the building, but it's not strictly by design.  In confusing
cases new addresses tend to get made up, usually by granting the (new)
access road a proper legal name, so it that sense what you said
describes how we do it.That's a long way of saying that it's messy
and that general rules don't always hold (in mass.us; not saying that
applies to .fi).

This is quite separate from access.  There are addresses on military
cases, and very often in residential complexes with gates that you need
a code/etc. to get through.   So it's not just access=destination but
access=private, and yet they are real addresses on named roads inside
the gate.


pgprjJqsYEerB.pgp
Description: PGP signature
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] addr:place support

[Greg Troxel]

Gerd Petermann gpetermann_muenc...@hotmail.com writes:

 I've coded the following simple approach:
  For each element (node/way) with addr:housenumber=* and addr:place=* and 
 addr:street!=*
 search the nearest routable way that has no name (mkgmap:street!=*)
 If the closest road is within a given range (150m), store the place name as a 
 possible road
 name. Perform a 2nd search to find also the closest road with a name or ref.
 If we find exactly one possible name for the road, use it.

I really don't understand what's going on here, but this strikes me as
strange; an address node with housenumber and place isn't about a
street.  Is the problem that in the Garmin format that the only way to
represent an address is via a road?  I wonder if there's a way to have
short non-rendered non-routable segments of roads to hang the addresses
on.


pgpKAkNbLHPJY.pgp
Description: PGP signature
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] address search and road names with refs

[Greg Troxel]

Here's a comment that's not only US-centric but also Mass-centric.  I'm
specifically talking about my town but that is normal.

The main road in my town is called Great Road.  It is also
Massachusetts Route 117.  There are 117 signs on it, and probably
someplace there is a Great Road sign.  Everybody local knows both names.
When giving directions to non-locals only 117 is used.

Addresses are always only using the road name, for example the Town Hall
is 375 Great Road.  Writing this as 375 Route 117 would get
understood, but would be viewed as confused.

Great Road shows up as Great Road with a SR117 shield (SR vs MA is a
tagging issue irrelevant to this discussion), arising from
  name=Great Road
  ref=SR 117

The address tagging on the town hall says
  addr:street=Great Road
and does not mention 117.  The rest assumes there are no address tags
with 117 in them.

That's a long lead in, but

* I think it's correct in this case that that the address tagging refers
  only to Great Road and not 117.

* mkgmap should definitely not present the primary address name as Great
  Road (SR 117), even if the label for the way looks like that.

* If one can search for 375 Route 117, but it doesn't show up if you
  don't search, that's fine.  (Nominatim does this, but you have to get
  the route ref right.  It then returns the address as Great Road.)

* mkgmap should offer Great Road as a street in address search, and
  not 117.

* both the 117 ref and the name should be in the find-street-by-name
  index

* There should probably be some tagging scheme to determine if Great
  Road or Route 117 should be considered the primary name to
  display/speak in navigation.  Which one is right really depends on
  local culture and which signs are more prominent.  But the style I'm
  using says e.g. Great Road sir 117 for a lot of these roads, which
  is highly useful.

In short, the ref for the road is part of the road's name, but not part
of any addresses on the road.  So mkgmap should only use the address:*
data for addresses, and not merge in any refs from the way that is named
by address:street.

If someplace an address is 375 Route 117, then arguably the way should
have a name=Route 117 in addition to ref, and the addr:street on the
building should say Route 117.

So I guess the question is how addresses work in a bunch of other
places.  Do people consider using the route number equivalent and a
completely ok thing to do?



pgpkuJa68UtFI.pgp
Description: PGP signature
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] roadspeed in default style

[Greg Troxel]

Bernd Weigelt weigelt.be...@web.de writes:

 Am Donnerstag, 12. März 2015, 19:21:42 schrieb Bernd Weigelt:
 I don't see any problem with Andrzej's speed rules, i will test them asap

 Hmmh, but i have some questions

 Example a motorway in Germany, tagged with maxspeed=none

 maxspeed=none  { set maxspeed=140 }
 ok, i unterstand what this rule does

I guess the trick is to figure out how to map the rules and other tags
to what speeds are reasonable to assume.  This seems like a place where
a tag that indicates typical speed would be useful; locals can set it to
what speeds most traffic is normally at, which is really what routing
wants to know.

But assuming unlimited motorways are 130 or 140 does not sound crazy to
me; uncongested Interstates in low-enforcement US states are like that.


pgpnSjPbMtXrr.pgp
Description: PGP signature
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Railway tracks drawn around station buildings

[Greg Troxel]

Andrzej Popowski po...@poczta.onet.pl writes:

 i always have treated default style as an example, not a real part of
 mkgmap program. I have assumed that some simplifications in this style
 are allowed ;)

I think that's a major bug.  The default style should the equivalent of
the released carto stylesheet and be the best known way to make a
reasonable broadly-usable translation of the database.

In general, mkgmap has been unnnecesarily hard to use; best practice
involves giving lots of options.  I realize  this doesn't 10% make
sense, but running it with essentially no options and the default style
should get the standard result (thought to be best for some group of
normal users with normal devices).


pgpMlEpILrn7b.pgp
Description: PGP signature
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Railway tracks drawn around station buildings

[Greg Troxel]

Gerd Petermann gpetermann_muenc...@hotmail.com writes:

 I have no idea how the carto stylesheet works. I don't even know how it looks 
 like.
 I guess this is used by the http://www.openstreetmap.org renderer?
 Please explain more detailed what you mean and how we could use it.

I didn't mean that mkgmap could use it.  One can look at the trunk of
the carto project as structurally similar to mkgmap in that it provides
a standard/default conversion.  The carto project seems to view their
default as being the default mapnik/carto render, and curates it to be
maximally useful for normal users (which is of course a hard thing to do
and unclear if it's ever right, but the point is that they try).

So, what I meant is that IMHO mkgmap should view the default style the
same way, as providing the best conversion known to the mkgmap
developers, where best means the conversion that is most useful to a
user with no special desires running on some typical class of devices.
The device target probably would be something reasonably modern, like an
oregon or etrex 30 or a nuvi from the last few years, although I haven't
found that anything newer than a Etrex Vista HCx to be all that
different.

 reg. options:
 I agree that the defaults are not very useful, esp. if you want a routable 
 map.
 I see no simple way to change that without creating trouble for existing 
 users.

My notion is basically that if someone pops up and says I want to
convert for a modern garmin and get all the features that are
supported, then what's recommended for them should be the default.

If people who don't want routable maps (or don't want something else)
have to add --no-route, I think that's ok, and it's better to make a few
people do that than to make almost everyone jump through hoops,
searching around for lengthy sets of command-line arguments.

Is anyone on the list actually trying to build non-routable maps?  I
would be curious as to why.

 One idea:
 We might provide a few commented sample configuration files, e.g.
 one for car-routing , one for bicycle-routing, and one without routing.

Ideally these would just be styles (unless there are games for computing
bicyles routes in car mode).   But sure, that sounds reaasonable.

Still, invoking mkgmap with no special options and the default style
should produce a map that works well for car routing when used in car
mode on normal devices.

I find that mkgmap is close to unique among programs I run into; it
seems very normal for what the development team thinks is the best mode
to be default.

THanks for listening!
Greg


pgpm464KL_XaU.pgp
Description: PGP signature
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Railway tracks drawn around station buildings

[Greg Troxel]

Andrzej Popowski po...@poczta.onet.pl writes:

 I think that's a major bug.

 It is a bug, but a minor one. It doesn't make mkgmap crash, it doesn't
 break map functionality and problem is not very visible on map.

I meant in terms of being usable and approachable for new users.  People
giving up is not so different than crashing in the end.

 The default style should the equivalent of
 the released carto stylesheet and be the best known way to make a
 reasonable broadly-usable translation of the database.

 This is impossible. I mean, default style creates a basic map. You
 should expect that it is correct and usable, but in no aspect you can
 call it the best. And the best rating depends on map purpose and
 user preferences, so better we stay at correct grade ;)

Of course it's impossible to achieve, but many steps toward the goal are
easy.  I was reacting to the notion that fixing the railway station
rendering didn't belong in the default style.


pgpGX8jWOqXDo.pgp
Description: PGP signature
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Manage drive-on-left/drive-on-right in resources\LocatorConfig.xml

[Greg Troxel]

Gerd Petermann gpetermann_muenc...@hotmail.com writes:

 thanks for the info. I don't have a City Navigator map,
 but I think I understand now how it could work.
 I think tt would be very difficult to implement that in splitter
 but in mkgmap it would probably be possible to do
 it by changing the clipping methods.

splitter could just split to rectangles until small enough, and then the
clippign could be done producing two.  That would result in more tiles
than some polygon-aware splitter, but my guess is that the # of extra
tiles that could have been avoided will be low enough.



pgpJTNfEfHuNq.pgp
Description: PGP signature
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] mkgmap in NYC

[Greg Troxel]

Gerd Petermann gpetermann_muenc...@hotmail.com writes:

 [1] This is because we use so called precompiled boundaries, and changing 
 them like that would
 require hard coded rules in the source.

That might be the right place to fix this.  Unfortunately New York
really is a weird case (I don't know of any other such case in the US),
but arguably it's important because a lot of people live there :-)


pgp73XxivvrtH.pgp
Description: PGP signature
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] mkgmap build greater than 3113 routes through barriers with access=no

[Greg Troxel]

Paulo Carvalho paulo.r.m.carva...@gmail.com writes:

Just checking: did you remember to use the --link-pois-to-ways option in
 your compile command?  Also, did you place the barrier node apart from the
 way or did you format a way node as a barrier? (the latter is preferable, I
 think.)

As I understand it, the semantics of OSM are that a barrier node in a
way does control access.  So it's a bug if mkgmap by default does not
produce a map that respects that.  Essentially, I'm arguing that
--link-pois-to-ways should default to on, following the principle that
there is a correct garmin representation of OSM semantics and that this
correct representation should be the default.


pgppcAJHQsTHb.pgp
Description: PGP signature
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] mkgmap build greater than 3113 routes through barriers with access=no

[Greg Troxel]

Paulo Carvalho paulo.r.m.carva...@gmail.com writes:

 Well, it can be dafaulted to on, but sometimes one may want to not
 translate node properties to ways.  For example: a map may have barriers
 and one may want to have such as POIs in an alert file for Garmin POI
 Loader instead of them interfering with routing.  It all depends on map
 purpose.

I can see what you mean, but there are standard semantics in the osm
representation, and therefore a map which does not follow those isn't a
proper representation of the osm data.

I did not mean to suggest removing the option to turn it off; I was only
really suggesting that it default to producing correct maps.  In general
I have felt that mkgmap accumulates options that one needs to give to
get the right answer, and that they should all default to on.
I think this is just an artifact of them being experimental for a while.



pgpLbkSAzCtil.pgp
Description: PGP signature
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] The --route option

[Greg Troxel]

Gerd Petermann gpetermann_muenc...@hotmail.com writes:

 I think we should remove (ignore) the --route option, as it is mandantory.
 If possible, we should allow to create maps that don't contain 
 a NOD section, I think this is wanted by some users.

I'm not sure what you mean.  It sounds like having
basic/advanced/routing is desireable from the list consensus.  But I
would suggest that routable maps be the default, when mkgmap is invoked
without special arguments.  Perhaps keep --net and --route, but allow
--no-net and --no-route and make --net and --route default (and of
course make route imply net)


pgpdKYO7YjpWV.pgp
Description: PGP signature
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Access handling trunk = mergeroads branch

[Greg Troxel]

WanMil wmgc...@web.de writes:

 I am comparing differences between the mergeroads branch running the
 compatibility mode and the trunk.

 Having the following way:
  access = destination
  highway = path

 The access bits are set as:
trunk | branch
 no_car   |   0   |1
 no_bus   |   0   |1
 no_taxi  |   0   |1
 no_foot  |   0   |0
 no_bike  |   0   |1
 no_truck |   0   |1
 no_throughrt |   1   |1
 delivery |   0   |1
 emergency|   0   |1

 0 = bit is not set
 1 = bit is set

 For delivery and emergency I am not sure if delivery/emergency is
 allowed if the bit is set or unset.

 At the moment the trunk allows all type of vehicles to use the given
 way. I think that's not good. The branch allows only foot to use the
 way.  What do you think should be the correct access bit mask for the
 given way?

I see multiple interlinked questions here.

One is if a given vehicle can physically use the way.  For highway=path,
I would say that car, bus, taxi, truck, delivery, emergency cannot.  If
they could, it would be highway=track instead.  So some of these bits
should not be set even for highway=path with access=yes (default case).
Or perhaps I'm confused and there is some other mechanism for this.

The other question is access=destination.  That's supposed to encode a
legal notion that one may traverse the way only if it's necessary to get
someplace that you can legally go.   My understanding of the Garmin
routing behavior is that it will not use disallowed ways in a route,
except at the ends.

So what this leaves me failing to grasp (and which I think is at the
heart of deciding the right answer to your query) is how these no_* bits
relate to a) physical feasibility, which can not be overridden by
'necessary to get to destination'  and b) permission, which seems to be
overriden.


pgpMy023PVTQZ.pgp
Description: PGP signature
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] [PATCH v2] Move maxspeed calculations to style file

[Greg Troxel]

Manfred Brenneisen manfred.brennei...@gmx.net writes:

 Thinking about maxspeed:practical, which can be used to initialize
 maxspeed in some cases, I thought about rural areas, which do not have
 any maxspeed, or maxspeed:practical information included in OSM data:

I think we do need tags for
  maximum speed that tends to be reasoable
  typical speed one can go


 The new curviness() function (useful for ways).

 Such a function could e.g. return the sum of direction change at every
 point, divided by the way#39;s length.

 This could give an estimation for the maximum practical speed.

This could be useful to drop the speed absent tags, but I would worry
that it would be very sensitive to how well the road is represented.

As a completely alternative approach, one could process tracks to obtain
maxspeed:typical values for ways.

A related concern is if some ways (the more commmonly-used ones) are
tagged, then the untagged, even scarier roads will be preferred by
routing.


pgp1Lql1Wl3wK.pgp
Description: PGP signature
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] [PATCH v1] garmin_area() style function

[Greg Troxel]

WanMil wmgc...@web.de writes:

 area_size() gives the area size on resolution 24. Your effects must have 
 another reason.

Maybe the function should be garmin24_area() instead, then.   I
understand that it's good to have area in garmin units because that's
the constraint this is intended to address, but this is confusing.

Presumably there is also an area() that is in m^2, for people thinking
in larger scales about logical size, not garmin units.


pgpm5YZ38LqmH.pgp
Description: PGP signature
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] tests passing on trunk?

[Greg Troxel]

GerdP gpetermann_muenc...@hotmail.com writes:

 some tests require input files which are not stored in svn.
 ant test doesn't download them automatically, you have to 
 execute 
 ant obtain-test-input-files 
 first. 
 @Steve: I also run into this problem again and again. Would it
 be a problem to change build.xml to do the download?

Thanks to you and Steve - I updated, redid 'ant build' and 'ant test'
and got a clean test run with zero failures.


pgpfK1royPrVt.pgp
Description: PGP signature
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] tests passing on trunk?

[Greg Troxel]

I have a 2 year old Mac Book Pro, running 10.7.  I recently updated and
installed Java 7 (from Oracle).  /usr/libexec/java_home prints:

  /Library/Java/JavaVirtualMachines/jdk1.7.0_21.jdk/Contents/Home

and I've set JAVA_HOME to that.

With r2644, and a clean checkout (removing even ignored files), ant
dist works fine and the output looks normal.

Then, running 'ant test' gets me 8 failures and 13 errors out of 291
tests.

So,

  am I using a reasonable jdk version?

  are these test faailures of concern (they seem to be)

  does this work ok for others?


Thanks,
Greg


pgpcjEeURClrt.pgp
Description: PGP signature
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Distributing mkgmp.jar

[Greg Troxel]

Felix Hartmann extremecar...@gmail.com writes:

 Am I right, that If I want to offer mkgmap.jar unchanged for download 
 (well zipped)
 I can do this, as long as I include the LICENSE file?

 I want to add a script to my maps, that automatically downloads 
 mkgmap.jar if not found, for gmapsupp.img creation.
 So for right now, I put mkgmap.jar plus license file onto my server 
 (http://openmtmbmap.org/mkgmap.zip)

IANAL and TINLA :-)

The license is GPLv2.  So you may distribute binaries (which I see a jar
as) if you either

  also distribute the source

  make a written offer to distribute the source

The conventional wisdom is that the written offer clause is best avoided
(as carrying obligations into the future).  So the easy thing is to put
a source .tar.gz (from which the binary jar was built) on the site as
well, which very clearly satisfies your obligations, even if people
choose to ignore it (see last paragraph below).


For reference, here are the relevant bits of section 3:


3. You may copy and distribute the Program (or a work based on it,
under Section 2) in object code or executable form under the terms of
Sections 1 and 2 above provided that you also do one of the following:

a) Accompany it with the complete corresponding machine-readable
source code, which must be distributed under the terms of Sections
1 and 2 above on a medium customarily used for software interchange;
or,

b) Accompany it with a written offer, valid for at least three
years, to give any third party, for a charge no more than your
cost of physically performing source distribution, a complete
machine-readable copy of the corresponding source code, to be
distributed under the terms of Sections 1 and 2 above on a medium
customarily used for software interchange; or,

c) - omitted, not relevant - 

If distribution of executable or object code is made by offering
access to copy from a designated place, then offering equivalent
access to copy the source code from the same place counts as
distribution of the source code, even though third parties are not
compelled to copy the source along with the object code.


pgpUnxUDH7rI1.pgp
Description: PGP signature
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Distributing mkgmp.jar

[Greg Troxel]

Felix Hartmann extremecar...@gmail.com writes:

 Okay - so inside the download I put the information from where one can 
 download the source, right?
 e.g. openmtbmap.org/mkgmap_src.zip

Sure, that would be fine.  Or just have

  openmtbmap.org/mkgmap/mkgmap_src.zip
  openmtbmap.org/mkgmap/mkgmap.jar
  openmtbmap.org/mkgmap/index.html (or autogenerated)

and consider yourself done, having made the source available in the same
place.

If you are only offering jars of code that is exactly a public svn
revision, then I can't see anyone caring about the jar/distribution/GPL
issue, but I think it is good for overall practice to be careful about
it anyway.

 And that src.zip should always be from the same date as the mkgmap.zip.

Yes.  The requiremnt is complete corresponding source, so that someone
who knows what they are doing (with java, in this case) could rebuild
it.

 However - what I don't understand is, why the official mkgmap-latest 
 download doesn't include the source then...??

My experience is that when the people who are maintaining a repo offer
downloads, and it's clear to everyone that the binaries are just built
From the repo, with no intent to hide anything, no one worries about the
details.  It's not hard to find the official sources starting with a
download URL.

But at

  http://www.mkgmap.org.uk/download/mkgmap.html

I see src links, which is fully satisfactory under 3a.





pgpF4GgtmSZRp.pgp
Description: PGP signature
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] new assertion?

[Greg Troxel]

GerdP gpetermann_muenc...@hotmail.com writes:

 Hi Greg,


 Greg Troxel wrote
 I have been running mkgmap with only occasional issues for a long time.
 I just updated to the latest svn, and got an assertion.  This was with
 java 1.6 on a mac, so I updated to 1.7.Then, I still get an exception:

 if you compile from source, please use  
 ant clean dist
 after an 
 svn update

I really thought I already did that.  But I just did it again, the build
is running.  Thanks for suggesting it.

(If I weren't switching JDK versions, I'd say that 'ant clean' being
necessary was a sign of a missing dependency.  But I am going from 1.6
to 1.7, so I get it that I have to start from zero.)

Plus, this was all more confusing than it should have been the way java
is on macs; I had to set PATH to get the 1.7 JDK to run.




pgpO5HGAE27bV.pgp
Description: PGP signature
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] new assertion?

[Greg Troxel]

I have been running mkgmap with only occasional issues for a long time.
I just updated to the latest svn, and got an assertion.  This was with
java 1.6 on a mac, so I updated to 1.7.Then, I still get an exception:

+ java -enableassertions -Xmx3072m -jar mkgmap.jar --max-jobs --latin1 
--description=OSM_gdt --country-abbr=US '--country-name=United States' 
--region-abbr=MA --region-name=Massachusetts --family-id=1500 
--family-name=OSM_gdt_family --product-id=13 --series-name=OSM_gdt_series 
--area-name=OSM_gdt_area --draw-priority=60 --overview-mapname=6324 
--tdbfile --style-file=/Users/gdt/CFERERRO/CF_GPS --reduce-point-density=4 
--reduce-point-density-polygon=8 --merge-lines --route --check-roundabouts 
--check-roundabout-flares --remove-short-arcs=6 --adjust-turn-headings 
--report-similar-arcs --report-dead-ends=2 --add-pois-to-areas --index -c 
template.args /Users/gdt/CFERERRO/CFMaster.TYP --gmapsupp
Time started: Mon May 27 20:59:47 EDT 2013
java.lang.NoSuchMethodError: 
uk.me.parabola.mkgmap.build.LocatorUtil.getNameTags(Luk/me/parabola/util/EnhancedProperties;)Ljava/util/List;
at 
uk.me.parabola.mkgmap.reader.osm.LinkDestinationHook.init(LinkDestinationHook.java:64)
at 
uk.me.parabola.mkgmap.reader.osm.OsmMapDataSource.pluginChain(OsmMapDataSource.java:170)
at 
uk.me.parabola.mkgmap.reader.osm.OsmMapDataSource.setupHandler(OsmMapDataSource.java:138)
at 
uk.me.parabola.mkgmap.reader.osm.bin.OsmBinMapDataSource.load(OsmBinMapDataSource.java:49)
at 
uk.me.parabola.mkgmap.reader.osm.OsmMapDataSource.load(OsmMapDataSource.java:112)
at uk.me.parabola.mkgmap.main.MapMaker.loadFromFile(MapMaker.java:144)
at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:56)
at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:230)
at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:227)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:722)
Exiting - if you want to carry on regardless, use the --keep-going option
Time finished: Mon May 27 20:59:47 EDT 2013
Total time taken: 412ms


template.args looks like:


mapname: 63240001
# description: OSM Map
input-file: 63240001.osm.pbf

mapname: 63240002
# description: OSM Map
input-file: 63240002.osm.pbf

mapname: 63240003
# description: OSM Map
input-file: 63240003.osm.pbf

mapname: 63240004
# description: OSM Map
input-file: 63240004.osm.pbf

mapname: 63240005
# description: OSM Map
input-file: 63240005.osm.pbf

mapname: 63240006
# description: OSM Map
input-file: 63240006.osm.pbf

and more.  This is from splitting us-northeast and a file I've been
using a long time with boundary=parcel with lot boundary data for my
town.


pgpLB6txFs4BC.pgp
Description: PGP signature
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] splitter and multiple files

[Greg Troxel]

I have been using splitter with multiple files for a long time.
Recently, I updated and got an error

This command works:

java -enableassertions -Xmx3072m -jar splitter.jar --output=pbf 
--max-nodes=100 us-northeast.osm.pbf

This command errors:

java -enableassertions -Xmx3072m -jar splitter.jar --output=pbf 
--max-nodes=100 us-northeast.osm.pbf LINCOLN_buildings_missing_from_osm.osm

Splitter version 282 compiled 2013-01-17T19:58:41-0500
cache=
description=
geonames-file=
keep-complete=true
mapid=63240001
max-areas=512
max-nodes=100
max-threads=8 (auto)
mixed=false
no-trim=false
output=pbf
output-dir=
overlap=auto
polygon-file=
precomp-sea=
problem-file=
problem-report=
resolution=13
split-file=
status-freq=120
stop-after=dist
write-kml=
--keep-complete is not supported for multiple input files. Please execute 
splitter once for each file.


But I am not giving the keep-complete option.   Also, if I split separately, is 
there some way to merge into tiles (these input files overlap)?

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

Re: [mkgmap-dev] Options

[Greg Troxel]

Thanks for putting time into the options issue.

As one of the too many complainers, my issue was not so much that
there were a lot of options, but that the typical new person's strategy
of ignoring them all did not lead to success.   What you're doing
addresses that point, and also reduces unneeded options.

From reading the option-review page, my comments as a fairly experienced
user who is NOT a mkgmap developer (omitting all where I concur):

-gmapsupp:
  It seems that there is always output a bunch of img tiles and a tdb,
  and this is either usable in mapsource, or convertable to gmapi
  format.  And one can produce a gmapsupp.img.  So perhaps integrate
  gmapibuilder and
--output=device,tiles,gmapi
  which selects one or more of the output formats.  And if no option is
  given, you get all three (which is easy to cope with via rm).  I don't
  like output==desktop since that really seems to mean for mapsource,
  but of course the actual name doesn't matter.

--levels:
  I agree this belongs in the style file, perhaps as a new file levels
  to go with points/etc.

--index:
  I vote for default on, and people can --no-index if they need to.

--check-foo:
  replace with --warnings/--nowarnings, defaulting to warnings.  Put in
  some output warning file, with a prefix by warning type for grep.
  Don't worry about enabling/disabling them individually.

style files should be able to reference a TYP which is associated with
the style.  Perhaps the user can override, but it seems that styles/TYP
really are linked.

Things I don't understand and thus am not commenting on:
  location-autofill/etc.
  precompiled sea



pgpbpIdNb6bg9.pgp
Description: PGP signature
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] address index question

[Greg Troxel]

--check-roundabouts \
  R 1 (and 7?) just do it and remove option.

For the check options, I think there's a tradeoff between useful
debugging and noise.  So I wonder if by default there should be a file
written (with a name derived from something) that has all the warnings,
with each type having a unique first word, so one can grep out the ones
one wants.  Then they can perhaps just be on, maybe with a single option
--no-check to skip the output.   I don't see a lot of value in
fine-grained warnings; getting the warnings that are the current
consensus seems like the right thing, and I don't see a machine that is
big enough to run mkgmap having trouble with the warnings file.

--add-pois-to-areas \
  R 8. But could be considered to be just making it work in the Garmin
  format. Are there any downsides?

The only downside is that if there is a node and an area, then you get
two, but one could say that there are two in the source data, so that's
ok.   I think it belongs on, because otherwise POI-type things
represented as areas vanish, index or not.

--index \
  5 and 6. I'd be inclined not to make it the default

I don't understand if the index code is stable enough, but I thought
that generally people should want this.   If that's off, though, it
makes sense to default to off until such time as it's stable.


Another usability comment is that I find the precompiled bounds
situation a bit confusing.  But maybe I haven't tried hard enough.


pgpbngUB2SwiD.pgp
Description: PGP signature
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] address index question

[Greg Troxel]

Richard Welty rwe...@averillpark.net writes:

 On 11/24/12 10:07 AM, Carlos Dávila wrote:
 El 24/11/12 03:08, Richard Welty escribió:
 $ java -jar ../mkgmap/mkgmap-r2379/mkgmap.jar
 capitaldistrict-2012-11-23.osm  --index --gmapsupp
 
   From mkgmap help:
 Note that option order is significant:  An option only applies to
 subsequent input files.
 So you should put your *.osm file last in the mkgmap call
 ah, i missed that. the change seems to have done it, address lookups in 
 the nuvi now work.

There's something else that I think is highly non-obvious to new people:
there are a ton of options (no surprise), but the defaults are not
really useful.  The norm among mkgmap users is to give a large number of
options, but for some reason (perhaps trying to keep behavior
consistent) these options are not default.   In the --remove-short-arcs
case, I don't understand why anyone wouldn't want it.

Another point is that you probably want --route in addition to --index.

FWIW, here are the options I use that I suspect everyone should use (or
mine are off from the consensus and I should change):

--tdbfile \
--reduce-point-density=4 \
--reduce-point-density-polygon=8 \
--merge-lines \
--route \
--check-roundabouts \
--check-roundabout-flares \
--remove-short-arcs=6 \
--adjust-turn-headings \
--report-similar-arcs \
--report-dead-ends=2 \
--add-pois-to-areas \
--index \

(Actually, everyone should use add-pois-to-areas is perhaps
controversial.)

I think it would be good for all options to have a --no-option variant,
and then to default each option to what the group consensus is in terms
of what should a user (who doesn't really understand all the subtleties
yet) who just wants to take OSM bits and make a map for their device for
general use want.


pgpbi3VLsjrsF.pgp
Description: PGP signature
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] immediate crash due to library issue??

[Greg Troxel]

I've been running mkgmap fairly regularly for several years.  I have a
script that runs splitter and then mkgmap, and routinely 'svn up' to the
latest (trunk) and 'ant build'.  Usually this works fine.

Today, I updated to:

  Path: .
  URL: http://svn.parabola.me.uk/mkgmap/trunk
  Repository Root: http://svn.parabola.me.uk/mkgmap
  Repository UUID: 25d90789-57f7-4ee0-8453-03a3dfeeeb22
  Revision: 2371
  Node Kind: directory
  Schedule: normal
  Last Changed Author: wanmil
  Last Changed Rev: 2370
  Last Changed Date: 2012-11-01 07:07:58 -0400 (Thu, 01 Nov 2012)

From a version probably in early October (svn reflog doesn't seem to
work :-).

Running mkgmap, I got:

Time started: Sat Nov 10 08:50:17 EST 2012
java.lang.NoSuchMethodError: 
uk.me.parabola.mkgmap.reader.osm.Tags.get(Ljava/lang/Object;)Ljava/lang/String;
at uk.me.parabola.mkgmap.reader.osm.Element.getTag(Element.java:50)
at 
uk.me.parabola.mkgmap.reader.osm.HighwayHooks.onAddNode(HighwayHooks.java:97)
at 
uk.me.parabola.mkgmap.reader.osm.OsmReadingHooksChain.onAddNode(OsmReadingHooksChain.java:64)
at 
uk.me.parabola.mkgmap.reader.osm.bin.OsmBinHandler$BinParser.parseDense(OsmBinHandler.java:122)
at crosby.binary.BinaryParser.parse(BinaryParser.java:124)
at crosby.binary.BinaryParser.handleBlock(BinaryParser.java:68)
at crosby.binary.file.FileBlock.process(FileBlock.java:135)
at crosby.binary.file.BlockInputStream.process(BlockInputStream.java:34)
at 
uk.me.parabola.mkgmap.reader.osm.bin.OsmBinMapDataSource.load(OsmBinMapDataSource.java:63)
at uk.me.parabola.mkgmap.main.MapMaker.loadFromFile(MapMaker.java:144)
at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:56)
at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:210)
at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:207)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:680)
Exiting - if you want to carry on regardless, use the --keep-going option
Time finished: Sat Nov 10 08:50:18 EST 2012
Total time taken: 903ms

I tried 'ant clean' followed by 'ant build' again, but that didn't help.

I looked at
  https://wiki.openstreetmap.org/wiki/Mkgmap/dev
and it references protobuf.jar and osmprotobuf.jar; I suspect the
problem may be that I had an old version.  I dimly recall a tool 'ivy'
that is supposed to deal with getting up-to-date versions, but I can't
find any reference to it in the sources or the wiki page.

So I wondered if the protobuf versions I had (fall 2010) were old.  I
removed all files in my working directory that weren't versioned (except
for a few text files of notes to myself), and rebuilt.  Now it seems
ok.  So there seems to be a bug in dependency tracking.


pgpzxyUdPMua7.pgp
Description: PGP signature
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Speed limit

[Greg Troxel]

RocketMan rocket...@unlimitedmail.org writes:

 If I set my Zumo660 to simulator mode and then let it simulate a ride
 I see wrong speeds simulated at times.

 The speeds based on road_speed tags work fine.

I don't understand what you mean by this sentence.

 When simulating riding on a road with a speedlimit=90 tag the gauge on
 the GPS says 100 and when on a road with speedlimit=50 the GPS shows
 60.

I am fuzzy, but my understanding is that there are several (8?) road
classifications, each with a defined speed, hard-coded into the
definition of the img format.  Speeds are mapped to the
closest/rounded/truncated or something.  Usually this is good enough for
routing.


pgpcrRydiKbcl.pgp
Description: PGP signature
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Problem transferring maps from Mapsource

[Greg Troxel]

On Sep 16, 2012, at 0533 , Geoff Sherlock wrote:

 The simplest way to test if it is the same error is to try the --latin1 flag 
 using the lastest (r2328) version of mkgmap. If this works then it will be 
 the same problem I was getting; which Steve now has a fix for. Once it has 
 been confirmed that the fix does not affect any other functionality it will 
 be committed; and any future versions of mkgmap will no longer need the 
 latin1 or code-page set.

I went back to svn trunk (r2328), and added --latin1.   I rebuilt (us-northeast 
extract, plus parcel data for my town).   MapInstall now permits selecting the 
tiles from the OSM build, and I'm sending a combination of those, contour 
lines, and proprietary data to an etrex vista HCx right now, which seems to be 
proceeding normally.

Thanks to you and Steve for figuring out and fixing this.

I read the documentation, and understand now that code-page is dependent on 
target device.  I wonder though if --latin1 should be default, if it's 
supported by most non-ancient devices.  (I do have a GPS V, but I haven't tried 
to build maps for it in a really long time!)

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

Re: [mkgmap-dev] Problem transferring maps from Mapsource

[Greg Troxel]

Steve Ratcliffe st...@parabola.me.uk writes:

 Since you use a mac the problem may not be the same of course, but do 
 you build your maps without --latin1 or --code-page? It's not confirmed 
 fully yet, but I noticed Geoff was not using a code-page and he has now
 narrowed the versions down to ones where this seems to be a likely problem.

Probably.  I don't remember trying to add that.

In general, I think it's a bug that one needs to give all these
arguments to mkgmap.  I would think that with no explicit arguments, the
current best practice for making a map from OSM data should happen.

It sounds like there is a bugfix for not using --latin1.   I can try to
narrow down the range further, or if that fix is put on trunk try it out
and report back.




pgpUv028QQqVE.pgp
Description: PGP signature
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Problem transferring maps from Mapsource

[Greg Troxel]

Steve Ratcliffe st...@parabola.me.uk writes:

 Hi Geoff

 So r2306 is the first revision that fails, and r2210 is the last time it
 works correctly.

 Thanks that is useful, but still a big range.

 I should have added the version just before 2306, because 2306 was a 
 large change so we need to rule it out.

 if that still fails then I have no more guesses as to what it might be 
 so the next revision to try is somewhere half way between 2210 and 2306.

 So I've created 2271 and 2298, hope you have time to try them out.

I'm having an issue too, but I ran 'svn log' and it seems that while
there are many revision numbers, there are far fewer commits under
mkgmap, maybe 12ish.   I will report back when I have some real data,
but for the last few months I've been unable to select mkgmap-built maps
in mapinstall (on mac).  That used to work fine.



pgpFPTrJZBqFE.pgp
Description: PGP signature
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] resolution, level levels

[Greg Troxel]

John Aldridge j...@jjdash.demon.co.uk writes:

 Thank you again. I think the fundamental thing I hadn't grasped was that 
 you can't just put a resolution tag on something to cause it to be 
 displayed at that resolution or greater, but that you have to in some 
 sense create the level first with the levels specification before you 
 can assign something to that level using either the resolution or level 
 tag.

Yes.  I think what's going on is that in the actual bits, there is (more
or less) a 3-bit field that specifies the level index, and then a table
of 6 levels, so you can't really encode arbitrary levels.  I'm not 100%
clear on that, but I think the above gives you a useful mental model.



pgpdAeVlwdwGy.pgp
Description: PGP signature
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Attribution of Garmin-maps

[Greg Troxel]

Thorsten Kukuk ku...@suse.de writes:

 On Wed, Sep 12, aighes wrote:

 Hi,
 how do you attribute your published maps in a few days?

 If I got it correct from ODbL-licence it should be something like that (in 
 case of its a derivative Database):

 According to http://wiki.openstreetmap.org/wiki/Legal_FAQ I will use
 now:

 for the license (--license-file)
 Map data (c) OpenStreetMap contributors
 (http://www.openstreetmap.org/copyright)

 for the copyright (--copyright-message)
 OpenStreetMap contributors, ODbL. See: 
 http://www.openstreetmap.org/copyright;
 (Garmin will add the (c) at their own in the output).

It seems that this license/copyright information should be in the
.osm/.pbf, and mkgmap should just carry it along.  Of course, combining
terms seems tricky for multiple inputs, but in the simple case making
the mkgmap user set license terms manually seems suboptimal.


pgpHsGEnCKUnO.pgp
Description: PGP signature
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Commit: r2314: Ignore access=permissive|designated|official just like access=yes.

[Greg Troxel]

Felix Hartmann extremecar...@gmail.com writes:

 However I don't really no how we could properly handle access=private - 
 knowing new Basecamp/GPS devices ignore all no settings except 
 motorcar=no (which is actually the reason carpool seamingly works).

I think the really hard thing about access=private is that if you don't
have permission (most people, presumably) you can't use it, but if you
do you can, and there's no good way to tell the GPSr or any routing
program what you have permission for.  But, while it's probably true
that for any given way most people don't have permission, it's probably
also true that most people navigating to a point which has to use that
way do have permission, so it seems sensible to treat access=private as
access=destination.


pgp4GhmbF4dIF.pgp
Description: PGP signature
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] access=permissive question

[Greg Troxel]

Minko ligfiet...@online.nl writes:

 Chris wrote:
 I think access=permissive is correctly mapped to access=yes in mkgmap.

 I have contacted the mapper but he doesn't agree with this.

 access=permissive means that the landowner gave his permission to access this 
 footway.

 Footways are meant to access by foot only. So no access for all other 
 vehicles.

So access=permissive on highway=footway is basically an error, unless it is a
walking path that isn't a public right of way, on which cars may drive
and people may walk.

 So the way is open for every mode of transport, cars included.
 
 If cars are not permitted foot=permissive is the correct tagging.

 If I map this road to foot=permissive, mkgmap will block this road too:

 It will add access = no  but it can't add foot = yes because there is already 
 a tag foot = permissive

That's a style file bug then.

In Garmin, there is no notion of permissive, so it makes sense to map
permissive to yes.

 Unless mkgmap doesnt set foot = permissive to foot = yes, Garmin doesnt know 
 what to do and will block this for all traffic including pedestrians.

 So we are back to the discussion about bicycles from this topic:
 http://www.mail-archive.com/mkgmap-dev@lists.mkgmap.org.uk/msg10590.html

 I would suggest to set all vehicles access with permissive to yes, so
 bicycle=permissive  bicycle=yes
 foot=permissive  foot=yes
 motorcar, moped, motorbike,hgv etc same

sounds right

 except access=permissive  delete access

huh?   shouldn't access=foo map to
  for all modes bar, bar=foo

before the permissive to yes (and official to yes) mappings?

Is this controversial, or just a matter of getting the code to do the
right thing?


pgpYqj2UVHb8y.pgp
Description: PGP signature
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] access=permissive question

[Greg Troxel]

I read the thread more.  It seems the core of the disagreement is about
whether the semantics of access belongs in java code or style files.

I don't understand the problem, because it seems like Felix, who wants
to have a bike map avoid bicycle=official routes, can use styles to turn
those tags into bicycle=no, and then not get routed over them, because
the java code will then see bicycle=no, and the fact that it would have
accepted bicycle=official as bicycle=yes doesn't matter.

The harder question in Felix's case is that, if I followed, he would
like to not ride on a road if it has an associated official cycleway,
because one can't, but if they are separate ways then maybe that's
tagged bicyle=no, and that works ok.


pgpC2zkgHcDz0.pgp
Description: PGP signature
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] My involvement in mkgmap and the default style

[Greg Troxel]

Marko Mäkelä marko.mak...@iki.fi writes:

 Long time ago, I got the impression from Extremecarver that each Garmin 
 unit can have a different built-in TYP file, which is used when no TYP 
 file is included in the map-set. My experience is limited to the Edge 
 705 and the GPSMap 60CSx. I do not care that much about the map 
 presentation, because I rarely go off-road. POI search is more important 
 to me.

I have the impression there is a default TYP-type style for various
families of units (etrex vista HCx is different from oregon 450, for
instance) for mkgmap maps w/o a TYP file.   So I agree with the above.

Let me know if this testing is helpful or I should test different way.

 Well, I think it could be useful to introduce a TYP file that goes with 
 the default style. What do you think?

Agreed.

People talk about styles and TYP for specific purposes.  I think a good
plan is to have a main style that tries to be comprehensive (hikers
don't care so much how the roads look and drivers don't care so much
about trails, so each can be optimized) and then to see where we are.
Issues that I see are:

  licensing: given ODbL and the complexity of license compatibility, CC0
  makes sense for style and TYP.  I don't think we as a community have
  any worry about someone taking styles private and spiffing them up and
  providing proprietary builds.  I think the big point is that we have
  to be careful about only including things with consent from copyright
  holders.

  style/TYP interface: TYP can describe a rendering for elements that
  are already normal, and it can describe rendering for line and point
  types that are not normally in use.   Ideally we could mix/match style
  and TYP, and I think that means having a plan for which codepoints
  have which meaning.  That will allow decoupling of figuring out the
  mapping from osm to codepoints (not just which, but whether to include
  and at what scale), and display of codepoints.

  TYP can be beyond-style: it seems fine to have a TYP define lots of
  things that a style doesn't use.  So a lot of people can use the same
  TYP.

  multiple codepoints for a reason: it's possible we could define a
  range of codepoints for the same semantics, and have multiple
  renderings in one file, so that the style could be changed to make the
  output change, without changing the TYP.  But maybe we should see how
  much conflict there is.

So I'm advocating:

  a definition of codepoints

  a default TYP file with a rough consensus render for those codepoints

  a default style that expects the default TYP file

  perhaps a 'basic' style that works w/o a TYP


I've been using Charlie's TYP file (and style) and think it's a great
improvement.  I wonder if it makes sense for everyone who is maintaining
a TYP to convert it to mkgmap input format and trim things for which
they can't grant CC0, and publish that.  I suspect that it would not be
too contentious to try to merge the best of the existing TYPs.


Other approaches are possible - I'm just rambling about how to manage
complexity and get the best maps with the least total brain time.

Greg


pgpRjLUFmBuRt.pgp
Description: PGP signature
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Commit: r2237: Merge of the build branch which uses ivy to obtain

[Greg Troxel]

GerdP gpetermann_muenc...@hotmail.com writes:

 sorry, I should have noticed this earlier. The build works fine when I am
 connected 
 to the internet. The problem:
 I am sometimes using a VPN connection to
 the company I was working for. When this is established, I have no
 connection to 
 the normal internet. If that is the case, the build doesn't work, it hangs
 in target 
 compile  because that is depended on download-ivy (see below). 
 It's not a big problem for me, but maybe there is a simple way to avoid
 this?

Does it fail if you've previously run a build, or does this happen every
time.  Needing the net to resolve ivy dependencies once in a build tree
is one thing, but needing the net all the time seems too much.  (I
haven't tried without a network yet.)


pgpjeXOtxUxHh.pgp
Description: PGP signature
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Downloading pbf files

[Greg Troxel]

Roger Calvert ro...@rogercalvert.me.uk writes:

 I have found in the last couple of days that Firefox (which updated
 itself recently) tries to open pbf files from the geofabrik depository
 rather than downloading them. Has anyone else noticed this? If so,
 have you found a solution? (A work round is to use Save As, but this
 should not be, and never used to be, necessary.)

My solution is wget.  Or rather, after understanding the directory
layout once with a browser, I have alway used wget, so I didn't notice
the wrong-mime-type issue.



pgpweHfbljfzB.pgp
Description: PGP signature
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] BaseCamp 3.3 and Routing

[Greg Troxel]

Charlie Ferrero char...@cferrero.net writes:

 Weird that it gives the option to avoid roundabouts. I would have
 thought people would want to do the opposite (ie *prefer*
 roundabouts).

Where I live there are two rotaries (what we call roundabouts :-) that
are referred to by the locals as the circles of death.  That
reputation is fading somewhat as there's been more enforcement of the
yield-to-those-already-in rule.  So I can see someone wanting that, but
I agree that it seems funny.

http://osm.org/go/ZfI4wPpa5-


pgpFS9sTmBgX4.pgp
Description: PGP signature
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] [PATCH v1] Performance improvement by removing unused elements before the style processing

[Greg Troxel]

WanMil wmgc...@web.de writes:

 Hi,

 this is another performance improvement:

 Usually the mkgmap input tiles are larger than the processed bounding
 box (splitter parameter overlap). So there are much many elements
 which are processed but thrown away at a late step in mkgmap.

 The patch tries to remove them much earlier before the style files are
 processed and before the LocationHook starts (which ignores them but
 that must also be calculated).

 The patch contains one drawback:
 Ways which have all its points outside the bounding box of the tile
 but which cross the tile are also removed. If that's a point the patch
 must be improved.

Isn't that the whole point of the larger bounding box, to not lose roads
which cross at corners?


pgpIVfDR7kRrr.pgp
Description: PGP signature
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] failure of splitter on parcel data

[Greg Troxel]

GerdP gpetermann_muenc...@hotmail.com writes:

 thanks for the feedback. I wasn't able to test it with the small sample
 because it covered a too small area.

Actually that file is all I use for parcel data (just my town) so far.
But I did a splitter run with the town parcel file plus the 6 new
england states as pbf (from geofabrik), and from that built a map that
seems to work fine, in RoadTrip and on an Oregon 450.


pgp3hr3t2HZbh.pgp
Description: PGP signature
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev