Marko (mainly), How does the sub styles idea work.? In commit 1209, where is the sub-styles? at \examples\styles I can see the default and noname styles. In the info file of the default style I can see base-style=contours_ft base-style=location base-style=waters Is this the sub-styles that will be included in the default style? Where are these sub-styles though? Suppose an included base-style treats an element a certain way, will the main style (default in this case) then ignore this element? So the base-style treatment overrides the main style? Will a continue statement in the base style then reverse this, so that the main style treatment will prevail? Then, in the case of 3 sub styles, if they all have actions for the same element: the first style will be used, and the rest ignored unless a continue statement is used in the previous style? A continue statement will have no effect if the previous sub style did not have a continue statement? Or should conflicting rules be avoided? Argh, I hope someone understand what I mean? I don't use the default style, but a style based on the default with a couple of tweaks for custom points & lines etc. Still I like to keep updating regularly to benefit from Marko's improvement in the style. So I copy my tweaks into the latest default styles manually. The sub style idea might make my manual operation unnecessary, if I can just include my own style into the default. Before any other included styles, if I understand it correctly. Bennie
If I may reply on part of my own mail: On 2011/11/24 20:00, Bennie du Plessis wrote:
Marko (mainly),
How does the sub styles idea work.?
In commit 1209, where is the sub-styles? at \examples\styles I can see the default and noname styles. In the info file of the default style I can see
base-style=contours_ft base-style=location base-style=waters
Is this the sub-styles that will be included in the default style?
Where are these sub-styles though? I forgot that a .jar is actually an archive, and when I went further into it with 7Zip I found the styles where it always are: mkgmap-r2109.tar.gz\mkgmap-r2109.tar\mkgmap-r2109\mkgmap.jar\styles\
Suppose an included base-style treats an element a certain way, will the main style (default in this case) then ignore this element? So the base-style treatment overrides the main style? Will a continue statement in the base style then reverse this, so that the main style treatment will prevail?
Then, in the case of 3 sub styles, if they all have actions for the same element: the first style will be used, and the rest ignored unless a continue statement is used in the previous style? A continue statement will have no effect if the previous sub style did not have a continue statement?
Or should conflicting rules be avoided?
Argh, I hope someone understand what I mean?
I don't use the default style, but a style based on the default with a couple of tweaks for custom points& lines etc. Still I like to keep updating regularly to benefit from Marko's improvement in the style. So I copy my tweaks into the latest default styles manually. The sub style idea might make my manual operation unnecessary, if I can just include my own style into the default. Before any other included styles, if I understand it correctly.
Bennie
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
----- No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1411 / Virus Database: 2092/4036 - Release Date: 11/24/11
The answer was in the mailing list al along posted by Steve: http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2011q4/012799.html and is just the reverse of what I thought: Bennie
On 24/11/11 18:53, Bennie du Plessis wrote:
The answer was in the mailing list al along posted by Steve:
http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2011q4/012799.html
and is just the reverse of what I thought:
Actually I am not against changing the order. I wrote code that works both ways and couldn't decide which one I liked best. Well I did decide which one I liked best at the time, but re-reading what I wrote, I was expecting it to work the other way too!! ..Steve
On 2011/11/24 21:02, Steve Ratcliffe wrote:
On 24/11/11 18:53, Bennie du Plessis wrote:
The answer was in the mailing list al along posted by Steve:
http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2011q4/012799.html
and is just the reverse of what I thought: Actually I am not against changing the order. I wrote code that works both ways and couldn't decide which one I liked best.
Well I did decide which one I liked best at the time, but re-reading what I wrote, I was expecting it to work the other way too!!
..Steve _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
----- No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1411 / Virus Database: 2092/4036 - Release Date: 11/24/11
It is fine this way. The user can also use it either way. The name BASE style makes sense in this way. If the order was reversed I would have understood SUB style I have added your initial post (more-or-less) to the wiki page. I don't feel comfortable doing a patch for the help file, maybe someone else knows how / wants to? Bennie
Hi
Suppose an included base-style treats an element a certain way, will the main style (default in this case) then ignore this element? So the base-style treatment overrides the main style? Will a continue statement in the base style then reverse this, so that the main style treatment will prevail?
What happens is exactly the same as if you took the points file in your style and appended the points file from the base-style, and the same for the other rule files. So, since the first rule that matches is used, then your definitions will be used in preference to any in the base-style. If you use continue, then it is possible that your rule will be used, and then a further rule in the base-style will be applied. Anything in the options file overrides the base-style. That's the way it is meant to work. If it doesn't then you can report it as a bug. I'll answer the multiple base-style case next, since I see you've posted again since I started this reply! ..Steve
On Thu, Nov 24, 2011 at 08:00:24PM +0200, Bennie du Plessis wrote:
Marko (mainly),
How does the sub styles idea work.?
In commit 1209, where is the sub-styles?
You mean r2109, right? It introduces the following styles under resources/styles: landuse waters contours_ft More is to come, as I get around to it. I am not sure if I am going to add all these, but this is the rough plan: boundaries leisure # most leisure/tourism things rail-bus # public ground transportation aero # airports, runways etc. car # parking, fuel stations restricted # military, prisons, etc. manmade # building=*, man_made=* commercial # shop=*, paid-for amenity etc. services # public or non-commercial services ways # all highway=* pipes-cables
at \examples\styles I can see the default and noname styles.
Oh, it did not occur to me to look at dist/examples/styles. Right, it only contains a copy of the default and noname styles. I do not see anything obvious in dist/build.xml. Steve, any ideas how to include all styles there?
In the info file of the default style I can see
base-style=contours_ft base-style=location base-style=waters
Is this the sub-styles that will be included in the default style?
Where are these sub-styles though?
They are included in the dist/mkgmap.jar (which really is a zip archive with additional constraints). That is why it worked for me.
Suppose an included base-style treats an element a certain way, will the main style (default in this case) then ignore this element?
I did not think of that yet. My aim is to split the default style to disjoint substyles. Then, once that is done, one could easily create different kinds of "sparse" styles. One that I have in mind would import only highways and waters and maybe amenities and shops, but no landuse or buildings.
So the base-style treatment overrides the main style? Will a continue statement in the base style then reverse this, so that the main style treatment will prevail?
I was going to initially avoid the continue statement in the substyles. Currently, only the default style uses it, for internet_access=*. But I think it could be useful for boundary=*, in case a river or highway carries and additional boundary tag.
I don't use the default style, but a style based on the default with a couple of tweaks for custom points & lines etc. Still I like to keep updating regularly to benefit from Marko's improvement in the style. So I copy my tweaks into the latest default styles manually. The sub style idea might make my manual operation unnecessary, if I can just include my own style into the default. Before any other included styles, if I understand it correctly.
Yes, my idea is to make it more modular, sort of building blocks that can be chosen and adapted. And I guess it would be desirable to allow the definitions in the base styles to be overridden, so that you would need to maintain only a small style that derives from the default style. One thing that the base-style idea does not seem to currently cover is the deletion of rules. Say, you are otherwise satisfied with the default style, but you want to remove all rules for power=line. This is not currently possible, as far as I understand. Or maybe something like this would do: power=line { delete power } Unfortunately, this would unnecessarily bloat the tags-list of the parser. If the style contains no rules for any power=* tags, the parser can discard such tags immediately. Not so if you have the above power=line rule in the style. Hopefully the TYP compiler and the substyles will invite people like you to contribute to mkgmap. Ideally, the substyles would be so flexible that users' custom styles would be very small, only a handful of base-style=* and some rules in points,lines,relations to augment, remove or change the built-in rules. Best regards, Marko
Hi
at \examples\styles I can see the default and noname styles.
Oh, it did not occur to me to look at dist/examples/styles. Right, it only contains a copy of the default and noname styles. I do not see anything obvious in dist/build.xml. Steve, any ideas how to include all styles there?
Yes, there is a section that picks out a few samples to include, I didn't want to just include everything. But I see the problem, we now have non-working examples! The code is in the dist target in build.xml: <copy todir="${dist}/examples"> <fileset dir="resources"> <include name="installer/*"/> <include name="styles/default/*"/> <include name="styles/noname/*"/> <include name="chars/ascii/row02.trans"/> </fileset> </copy> Perhaps we shouldn't have the examples directory at all, I suspect it causes more confusion that anything else. If we do have them, they should be hand written for the purpose of demonstrating how they should be written. ..Steve
How does this work with base styles? I would like to include base-style=landuse (which seems stripped out of the default style?) but I get StyleImpl.java:140 errors. In the default style I see these lines in the info file: base-style=contours_ft #base-style=location base-style=waters Only if I remove those 3 lines in that info file, I can run mkgmap (r2140) without errors. I have copied all the substyle folders (like contours_ft, waters) to the same directory (styles) as the default style folder. My args file looks like this: style-file: styles\default generate-sea: multipolygon,extend-sea-sectors bounds: c:\Downloads\bounds latin1 code-page: 1252 tdbfile location-autofill: bounds,is-in,nearest name-tag-list=name,name:nl,name:fr,name:de,int_name show-profiles=1 ignore-maxspeeds remove-short-arcs merge-lines add-pois-to-areas add-pois-to-lines min-size-polygon: 4 preserve-element-order keep-going net route index nsis
Hi On 12/21/2011 06:51 PM, Minko wrote:
How does this work with base styles? I would like to include base-style=landuse (which seems stripped out of the default style?) but I get StyleImpl.java:140 errors.
I posted a patch for this before, but it should be ignored as it doesn't solve the real problem. I think I now understand what the real problem is.
In the default style I see these lines in the info file:
base-style=contours_ft #base-style=location base-style=waters
Only if I remove those 3 lines in that info file, I can run mkgmap (r2140) without errors. I have copied all the substyle folders (like contours_ft, waters) to the same directory (styles) as the default style folder. My args file looks like this:
style-file: styles\default
The following works in this situation: style-file=styles style=default and it would also pick up the missing styles from the classpath. This is because --style-file is the location of a collection of styles and the --style argument picks out one of the styles from that location. Using --style-file=styles/default is really a shortcut for when there is only one style in the collection. So in this example, mkgmap will read the style 'default' from the directory 'style'. For the base-style 'contours_ft' it first looks in the 'styles' directory and if not found there, then it will look at the builtin style location. The bug is that if --style-file=styles/default, then it should fail to find the base-style and give an appropriate error -- or it should find it, if it is one of the built in styles as in this case. ..Steve
Thanks Steve, it works, except for the base-style=location. If I replace the loaction rules from the default style files to the location styles, the locator doesn't do its job anymore. Is this a known issue? Steve wrote: The following works in this situation: style-file=styles style=default and it would also pick up the missing styles from the classpath. This is because --style-file is the location of a collection of styles and the --style argument picks out one of the styles from that location. Using --style-file=styles/default is really a shortcut for when there is only one style in the collection. So in this example, mkgmap will read the style 'default' from the directory 'style'. For the base-style 'contours_ft' it first looks in the 'styles' directory and if not found there, then it will look at the builtin style location. The bug is that if --style-file=styles/default, then it should fail to find the base-style and give an appropriate error -- or it should find it, if it is one of the built in styles as in this case.
Sorry, I just found out that I had to put the locator rules on top to make this work: style-file=styles style=location And in the location info file: base-style=default base-style=contours_ft base-style=waters base-style=landuse
I still have problems rendering my map with sub=styles. I now have in the mkgmap parameters: style-file=styles style=location In the directory styles I have subdirs "location" and "default" Location contains the files: info, lines, polygons, points and version; And in the location info file, there is a rule base-style=default Default subdirectory contains all the usual files except the locator style rules. Now I have observed that the overlays file in the default subdir is not processed, but if I move this file under location style subdir it renders ok. Is this intended or a bug? Where do I need to put other files like relations? Under default or move it to location as well?
Hi
Now I have observed that the overlays file in the default subdir is not processed, but if I move this file under location style subdir it renders ok.
Is this intended or a bug? Where do I need to put other files like relations?
Yes I guess it is probably a bug for the overlays file not to be used. However its not straight forward, what would you expect to happen if both the main style and the base style had an overlay file? ..Steve
participants (4)
-
Bennie du Plessis -
Marko Mäkelä -
Minko -
Steve Ratcliffe