logo separator

[mkgmap-dev] [PATCH v2] - styling for the power user

From Felix Hartmann extremecarver at googlemail.com on Fri Aug 7 18:18:10 BST 2009

2009/8/7 Steve Ratcliffe <steve at parabola.me.uk>

>
> Hi
>
> > "macro/programming language". As you say, the style files were never
> > intended to be able to do the things we want them to do now. So what
> > can we do about that?
>
> The style system was designed to do the little things that were
> hardwired into the code directly from the style itself.  It also
> pretty much pre-dated routing so that the fact that you can
> have two separate names for a road (say a name and a reference when
> both exist) cannot be implemented.
>
> I would like to know what people want to do that is not possible.
> Is anyone other than Felix doing something that is difficult with
> the current system?
>
> Then I need to work out if the main problem is that actions are, in
> effect, run in a random order.  Would guaranteeing that actions were
> run in the order that they occurred in the file help?  It would
> certainly make it possible to work out what a set of rules did.
> I probably shouldn't have allowed stand alone actions on rules without
> a type, without also making them ordered.


To me this would be enough. Best make sure that it is also possible to run
several actions against the same road.

I think the most difficult is getting the name of a road right, other things
are much easier, as there are not many possibilities. Only in case we have
the extended types completely covered, it might become a bit more complex,
but nothing I can imagine that I couldn't do right now.

The other big thing missing for me (other than the extended types) is making
corners rounder.... but that has nothing to do with the style-file. As very
sharp corners for bicycle/pedestrian impose a too heavy time toll.

One thing I have noticed on Garmin Swiss topo maps, is that the calculated
length of some ways that curl down mountains is underrated by up to 30%,
maybe they do this on purpose to improve the chance of the ways being chosen
for autorouting. Off course having the big disadvantage that those roads
will not calculate the proper distance anymore. Maybe one could make the
autorouting data to believe the road is straight but longer, I don't know
whether that is possible.


>
>
> I think it can be done without a large performance overhead (at least
> if you make minimal use of actions), but if it is not going to
> help any power stylers then it is not worth doing and we should
> do something else instead.
>
> > implement all those nifty new tricks I'd like to have a plug-in
> > interface in mkgmap to add my own Java routines. That could be plug-in
> > at compile time, no need to make it too complicated. It would be a
> > start to sort through all the classes and provide some documented
> > hooks to plug-in your own routines. Then in the style files one could
> > "invoke" the plug-ins that one would like to use.
>
> I remember thinking that a style could have a classes directory
> probably for type resolvers although I forget exactly why.  It
> would certainly be possible, although I would like to see if
> can make the current system work better for people.
>
> ..Steve
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20090807/041268cf/attachment.html 


More information about the mkgmap-dev mailing list