Hi
On Sun, Jun 28, 2009 at 08:52:03AM +0100, Richard Fairhurst wrote:
> I was going by the docs on http://www.mkgmap.org.uk/page/tile-splitter
> which suggest "The default [for max-nodes] is fairly conservative, I
> think you could increase it quite a lot". Clearly not by 50% though. ;)
Yes t
Hi Ivan
>I downloaded fresh r1067. Unpacked it new directory, cleaned up mapsource
>registry, etc.. added attached files (reg, cmd file renamed to .txt and
>xml file to fetch OSM data) and I still get lower case letters in
>resulting .img file
I ran the commands in your script to
On Wed, Jul 01, 2009 at 06:13:27PM +0200, Clinton Gladstone wrote:
> Let us know if this is enough information for you. If not, I can send
> you the patches and further information directly.
I know have a fair amount of time to work on mkgmap and applying these
pathes is going to be one of the fir
Hi
> In PERL it is builtin "tie" functionality, I have, however, no idea
> what is the used data structure in mkgmap and splitter and how to
> translate the trick into Java.
> If you think that the change is trivial and point me to the critical
> section I might see if I get it implemented.
I was
Hi
So the highway shield patch is in, sorry about the delay, let me know if that
is not the latest
or if there are any updates.
I have a couple of questions
First is the PrependFilter still really needed?
Also it doesn't appear to work with 6 bit. I think the documentation
is overly complex
Hi Richard
> The rules Im using (in lines) are this:
>
> ncn_ref=* { set ncn=yes; echo 'Converting from ${ncn_ref}'; }
> ( highway=bridleway | highway=byway | highway=cycleway |
> highway=track | highway=footway) & ( ncn=yes | rcn=yes )
> { set offroad='yes'; echo
Hi
> I would like to thank all who contributed to making highway shields
> possible in mkgmap. Although I am unsure if I can use the changes
> directly, given that I am using polish format files as input, I have
Yes we need to read the polish format symbols too. If there is not a patch
alr
Hi
> Could you please tell me which "Map" would have to be "reimplemented"?
> There was a lot of changes (and file deletions) since version 3.
Yes, it is completely different code.
The original code (r3) did nothing except attempt to save the nodes to a
berkeley db. I then gave up on it and wro
> As roads can have up to 4 labels we could set one of the labels
> to be the original road name and then the searching would work as
> before. The problem now is that by altering the name in the style
> file we lose the original name.
> Something to ponder.
Funnily enough I was just adding the
Hi
On Sun, Jun 28, 2009 at 08:26:33AM +0200, Nop wrote:
> According to the Wiki page, the last version recommended as reasonably
> stable is 858. As I needed some particular improvements, I am using
Yes 858 is now ancient. I think it doesn't even do routing with OSM input
files.
> might in ord
Hi
> This resulted in a JOSM .osm file with multiple bounds elements.
> mkgmap couldn't handle this and clipped the map to one of them
> (presumably the first one) so my generated map showed only a part of
> the area I had data for.
Yes the current behaviour is never what anyone expects.
I am wan
Hi
> So what will happen with this example.
>
> highway=* {set tag_a=yes}
> tag_a!=yes {set tag_b=yes}
> tag_a=yes [0x01 resolution 20]
> tag_b=yes [0x02 resolution 20]
> highway=* [0x03 resolution 20]
>
> Will all highways be converted to 0x01, 0x02 or 0x03?
My guess was 0x01. But it turns ou
Hi
> And I think, if I would change the second line to
>
> highway=* tag_a!=yes {set tag_b=yes}
adding in the missing '&' sign:
highway=* & tag_a!=yes {set tag_b=yes}
Then that is allowed, and the result would still be that all
highways were 0x01.
> it wouldn't change anything, or would it?
Hi
> http://wiki.openstreetmap.org/wiki/OSM_Map_On_Garmin/Cycle_map
> http://svn.openstreetmap.org/applications/utils/export/garmincyclemap/network/
> http://www.openstreetmap.org/user/Richard/diary/6949
Looks great! Is there anything that you would really like it to do that it
doesn't yet?
..S
> I tried to run the splitter on massachusetts.osm (from cloudmade)
> because my mac with a paltry 2G of ram couldn't cope in one piece. I
> got an exception about bad versoin number in class file, and I wonder if
> the splitter requires java 1.6? It would be nice if all the osm java
> code work
On Wed, Jul 08, 2009 at 07:59:16AM -0700, Apollinaris Schoell wrote:
> Soylatte is a Java 1.6 implementation for Intel based Mac. Details are
> available here
> http://landonf.bikemonkey.org/static/soylatte/
Have you tried the OpenJDK6 Beta 1 version, does it work well?
..Steve
> Personally, I think the highway tag should take precedence over the
> boundary tag and these lines should be moved below the highway stuff.
>
> Whaddyathink?
I say, lets do it.
..Steve
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http:/
Hi
I'm am forwarding this email, with permission, in the hope that someone
can help before I able to look at it at the weekend.
- Forwarded message from Valentijn
Date: Wed, 08 Jul 2009 10:47:43 +0100
Subject: OpenStreetMap e-mail - mkgmap bug report
Hello Steve,
Marvellous piece of work
Hi Marko,
I have applied your patch from Ben's updated patch and made your changes.
Hope that is all correct, could you check please.
Thanks,
..Steve
> I compared your patch to mine. I only noticed two differences:
>
> First, in my patch, truck stops have precedence over manned fuel stations
Hi
> I tried to compile a test map to go trough POIs on my eTrex legend.
> java -Xmx512m -jar mkgmap.jar test-map:all-elements
>
> provides me just with a list of errors:
> Can't set city point index for 0x10,0x22 (too many indexed points in
> division)
> Can't set city point index for 0x10,0x2
Hi
> Weird artifacts at the border I can cope with and were to be expected.
> The places I'm visiting are hundreds of miles apart and not near any
> borders so that in itself shouldn't be an issue
For routing to work across the tiles, the road end point has to be in
exactly the same place (well w
Hi David
> I produce a map from Geofabrik Ireland file. I discovered that Saint
> Stephen's Green park in the Dublin city center is not well rendered (in
> the past it was OK). It looks like a polygon on OpenStreetMap.org but if
> you take a look in data, it is both a barrier=fence (rendere
Hi
> http://wiki.openstreetmap.org/wiki/OSM_Map_On_Garmin/MDR_Subfile_Format
>
> Or does this reflect the current state of our knowledge?
That is just a small amount of what we know. The file is however very
large with many sections. What is known may be enough to get something
working but I w
> In my previous post i proposed a patch that solve this problem but it is
> still not observed nor committed. I don't know why? :(
Sorry about that, I think that the patch is good, I've been busy with other
things in last few months, but I should have more time soon.
Also the ordinary mapnames
Hi
Since no one replies to my mail, I'll do it myself ;)
Thanks for studying the problem so closely - it is very useful.
What I found is the following. Splitting a file with a border will
produce a file that has the exact "bounds", without the overlap, in the
resulting map.
That is inten
On 17/07/09 22:59, Valentijn Sessink wrote:
Steve Ratcliffe schreef:
That is intentional; the bounds should not overlap and should meet exactly.
Are you really (as in really-really-really) sure about the fact that the
Oh, I'm not usually sure about anything.
I do know what yo
Hi
I've run your example and looked at the bounding boxes of everything
important that I know about.
First the actual bounds as given in the input files.
All the bounds below I believe should be exactly equal to this.
Also the first number on the first line should be the same as the
third numbe
On 19/07/09 14:30, Torsten Leistikow wrote:
with mkgmap version r-1067 all my style files were ok. Now version
r-1087 reports some errors. For example a ';' is not accepted any more
in a tag value.
I don't think a ';' has ever been allowed unless the tag was quoted.
So you have to say highway
Hi
But also the following line from the style file is rejected:
highway=trunk& junction=roundabout& access!=* vehicle!=*& motorcar!=*
[0x26 resolution 18]
What is wrong with this line?
There is a missing '&' between access!=* and vehicle!=*
..Steve
__
On 18/07/09 13:09, Steve Ratcliffe wrote:
Hi
I've run your example and looked at the bounding boxes of everything
important that I know about.
First the actual bounds as given in the input files.
All the bounds below I believe should be exactly equal to this.
Also the first number o
Hi
Just a note that the mailing list and website are being moved onto a new
server. There may be a problem or inconsistency if things are slow to
update.
..Steve
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailm
Hi
What do people think? I'm happy to work on the above though I must
confess up front that my spare time is quite limited so please don't
expect too much too soon!
It all sounds good. Well worth trying each idea out to see if it
makes an improvement.
Although the .get() is not used at the mo
> My problem is that if laurels8.mp contains a full set of contours,
> hydrography and land cover my 6324000.img file shows a corresponding
> 07250732 quadrangle, but if laurels8.mp consists only of ways, there is
> no quadrangle for 07250732. Therefore, while I can see the ways in
> MapSource, I
> And when I look to the Coast, I'll not see Water.
>
> Are there People working on that?
As far as I know, no one is working on creating sea polygons.
It would be a very useful feature if anyone want to step up
and do it.
Regards,
..Steve
___
mkgmap-
> receiving some off-list encouragement to do so. Here's a patch which
> adds a README.INDEX that describes multiple readme files. If people
> Besides what I listed below, I think we need a README that explains to a
> newbie: if you want to make an img from osm data to use, what options
> shoul
Hi
> // TODO need to change this
> private final int topBits = 15;
>
> the first level in the overview map?
>
> If so, then could it not be read directly from the detailed maps, rather
> than being a constant? I noted the TODO.
Yes that is exactly right. It should be calculated so that the whol
On 21/07/09 00:35, Clinton Gladstone wrote:
> I found that highway names with spaces in them, such as "A 1" would be
> displayed in the shield as just "A".
Thanks, looks like a bug to me. I will commit your fix
and a test for it.
..Steve
___
mkgmap-d
On 19/07/09 23:58, Chris Miller wrote:
> Good news - with my changes the areas.list file was generated fine, peaking
> at maybe a 3GB heap.
Cool.
It is also worth noting something that osmcut (an other map splitter)
does. It has two modes; one where a map is used for when the input file
is s
Hi Chris
On 22/07/09 12:17, Chris Miller wrote:
> 1) If a way covers more than one area, should ALL nodes for the way belong
> to all of those areas, or should each area only contain the nodes that lie
> within it, regardless of ways? Currently the latter seems to be the case
> but that feels wro
> I've done some more README work. I am finding a lot of information on
Thanks for this, I'll look through it and let you have my thoughts.
One thing that is worthy of note since I see it a lot, is that there
is no need for a --net if you also have --route as the route
option also creates the
Hi
On 27/07/09 14:09, frmas wrote:
> My question is related to the style files:
> Where do I have to use the parameter "--style-file=xx".
> I use it two times when I create the gmapsupp.zip file, but maybe one is
> useless.
The style file is only used to convert from .osm to .img. So
if you
Hi
Could everyone who is interested in this please try the attached patch.
It seems to work on the example I was looking at, but of course problems
may just have moved elsewhere so please check thing are OK
more widely. It would be good to know if it makes a difference to
inter tile routing
Hi
> And in my style the lines-file contained the following rules:
> highway=null_null& layer<0 [0x01 resolution 10]
> highway=null_null& layer=0 [0x02 resolution 10]
> highway=null_null& layer>0 [0x03 resolution 10]
> highway=null_null& layer='-1' [0x04 resolution 10]
> highway=null_null
On 29/07/09 20:53, Torsten Leistikow wrote:
> Steve Ratcliffe schrieb:
>> I would say that the second result would
>> be very strange as the rules for 0x2 and 0x5 are exactly
>> the same and the 0x2 one comes first and so should win.
>
> You 're right, I have to
Hi
I know it was quite a while back when you posted this, sorry.
On 24/06/09 21:56, Marko Mäkelä wrote:
> My friend, who owns a Garmin GPSMap 60CSx, notified me of a character set
> problem in a tile name of my map. I wasn't aware of the problem, because
> my Edge 705 does not display map tile
Hi
> I did not. If I do, the symbols appear correctly. I'm not familiar with
> neither the Garmin encoding nor mkgmap's handling of it, but would it be
> possible to add the codes for the symbols to the names in a way that
> they work with both 6bit and 8bit encoding?
Sure it just looks like a bu
> *G:\Willem\Mijn documenten\mkgmap\mkgmapr1117>java -jar mkgmap.jar
> --style-file=fietskrt fiets2.osm*
If your style is zipped as attached to your message then you need to
give the full name fietskrt.zip
Does that help?
..Steve
___
mkgmap-dev maili
On 05/08/09 10:48, Mark Burton wrote:
>
> +--enable-assertions
> + Turn on assertions in the code. This will make the program
> + more likely to abort and less likely to do the wrong thing.
> + Use of this option is recommended.
> +
>
> Surely this is either -ea or -enableassertions
Hi
On 06/08/09 13:56, maning sambale wrote:
> According to this:
> http://wiki.openstreetmap.org/wiki/Mkgmap/help/usage#Contours
> "Contours were added in r1079. They were removed in r1080 as they do
> not compile without extra packages. "
There are several different input file formats supported.
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 als
Hi Felix,
I am trying to work out what doesn't work here. In general
anything that relies on the order that actions are run in
will not work reliably (see my previous post).
I will put each question/comment in a separate post to keep
things clear and separate.
The following part of the file c
With these two rules, even if they are run in same order as
they are written, the second one could never
have an effect if ${name} is defined.
> highway=* { name '${name} (${ref})' | '${ref}' | '${name}' }
> highway=* { name '${name} ${name1}' | '${name1}' | '${name}' }
This is because you can o
Hi Felix
> highway=* {
> name| '${ref} ${name} ${name1} ${name2}'
> | '${name} ${name1} ${name2}'
> | '${ref} ${name1} ${name2}'
> | '${ref} ${name} ${name2}'
> | '${ref} ${name} ${name}1'
> | '${ref} ${name}
>
On 09/08/09 13:25, Christian Gawron wrote:
> Thanks for adding the Ant task!
No problem. I am going to change though it so that it doesn't require
making a bunch of methods public on the command line reader.
> Maybe it's a good idea to move the GeoTIFF stuff in the extra-dir, too.
Yes, that is
Hi
I am going to merge all the multipolygon fixes.
Including, if appropriate, the sea polygon changes.
In addition to the patches sent to the list I also
have permission to use the attached patch from Olaf Kähler
which he describes as follows:
> I guess, mkgmap has a bug with "vanishing islands"
Hi
> One thing I noted during the testing of this fix is that setting
> max-nodes=30
> for europe.osm triggers a lot of "Node in too many areas" warnings, due to
> a fair number of nodes ending up in 5+ areas. I can partially or even
> completely
> fix this as long as the number of nodes s
On 09/08/09 18:41, Charlie Ferrero wrote:
> 1. Currently, if you invoke mkgmap with the --style-file= tag and point
> to a non-existent style file (or incorrect path), mkgmap continues
> regardless (and applies the inbuilt default style, afaict). Can I
> suggest a patch to mkgmap that at least m
Hi
> Good question, I was wondering that myself. It looks like with so few nodes
> per area, we end up with some very thin areas that for example result in
> the two areas on each side, plus two adjacent areas above, being included
> in the extended bounds/overlap if a node is in the centre of th
Of course I forgot to attach the patch and examples... trying again.
..Steve
mkgmap-multipolypatch-v2.tar.gz
Description: GNU Zip compressed data
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mk
Hi
On 10/08/09 10:52, Chris Miller wrote:
> Given that it's only when a relatively low number is given for --max-nodes
> that we run into any trouble, maybe it's best to leave at 2000 for now. Is
> there a reason why people would want to use such a low number? Smaller tiles
> so more flexibility
On 10/08/09 14:29, Nop wrote:
> What is the expected strategy for splitting a polygon with multipoly
> relations into several parts within one tile? How does splitter handle
> this? Has there been some work around this area recently?
The patch I forwarded onto the list this morning was dealing
w
Hi
On 10/08/09 22:37, Chris Miller wrote:
> Hi Steve/anyone,
>
> Can someone please clarify exactly how DivisionParser.round(Area) is
> supposed to behave? My understanding is that it is taking the area
> passed in and rounding
On past experience, it is pretty safe to assume that any rounding co
On 10/08/09 20:14, Ondrej Novy wrote:
> steve commited this change:
> -highway=residential | highway=living_street [0x06 road_class=0
> road_speed=2 resolution 21]
> +highway=residential | highway=living_street [0x06 road_class=0
> road_speed=2 resolution 23]
> (rev 1118) and say it's my patch
Hi
> So test 3 still fails, even after applying the patch, or did I do
> something wrong applying the patch?
No test 3 still failing was a known problem, there are still cases where
it was known not to work.
..Steve
___
mkgmap-dev mailing list
mkgmap-
On 10/08/09 15:07, Nop wrote:
>> There are other outstanding mulitpolygon fixes that may help too.
>> The first of which is applied to the multipolygon branch:
>
> I am not sure I understand. Do maps split with splitter also have the
> problem of missing polygons at the moment?
The splitter does
Hi
On 12/08/09 08:52, Felix Hartmann wrote:
> How comes that the newest mkgmap versions write in information into the
> last level, instead of leaving it empty?
What tool is showing you that it is not empty?
I have run a quick test on the latest and it looks empty:
RgnDisplay output:
-
Hi
Is there any problem with this option, such that you might not want
to use it?
As I understand it, if you do not give it then routing will not work,
as we know (or believe) that all routing arcs have to be more than 5.4m.
If that is so, then we should just set the required behaviour whenever
Hi Mark,
On 12/08/09 11:23, Mark Burton wrote:
> I believe that the mimimum distance will depend on lat/lon because the
> real constraint is that the source and target nodes must not have the
> same coordinates (resolution being 360 deg / 2^24)
Are you sure that is the real constraint?
The 5.4
On 12/08/09 15:12, Valentijn Sessink wrote:
> A nice success report: I built a map of Germany for my Garmin Nuvi 205
> BeNeLux& France. And guess what? Even inter-map-routing works! I can
> route from Amsterdam to an obscure place somewhere half way in Germany,
> without any problems. :-)
So wa
Hi Mark
> Well, I don't mind. Would you like the default min arc length be 5.4m
> rather than 0? Easily done.
Yes I would like the default to be 5.4m as that is the best information
we have.
I also see no need to remove short arcs when not routing as that case
is handled fine by the existing c
On 12/08/09 17:13, Mark Burton wrote:
> What we want is that the result of RouteArc.convertMeters() is
> not less than 1. So with the values it has at the moment that requires
> a min arc length of 4.878 metres. If we set the default to 5m, we
> should be chuckling.
>
> It could look like the att
Sorry about previous blank email...
On 12/08/09 17:13, Mark Burton wrote:
> What we want is that the result of RouteArc.convertMeters() is
> not less than 1. So with the values it has at the moment that requires
> a min arc length of 4.878 metres. If we set the default to 5m, we
> should be chuck
Hi Felix
>Opening the .img in gpsmapedit shows me that level 5 is the last level at
>resolution 15. Now having an empty overview map and seeing motorways and
>coastline in level 15 in Mapsource I have to assume that the last level is
>not empty (otherwise I could not see it in Map
> Problem 3:
> Small multipolygons are rendered correctly but I have a problem with larger
> multipolygons. The inner holes are visible at low zoom levels, but they
> disappear if I zoom in. I don't know if this is a problem of the Garmin
> software or if this is an effect of a filter in mkgmap.
>
On Sat, Aug 15, 2009 at 09:16:36PM +0200, Elrond wrote:
> In the long run, we should consider, if this should be
> somehow modifiable by the style. Either by letting the
> style say "Don't go and create a POI" or the other way
> round.
It is already possible for a style to set options. All we ha
> polygons patch of Christian. The sea polygons patch is already committed to
> the trunk, so I don't think it's a good idea to add version 1 of my patch to
> the trunk afterwards.
The sea polygons patch is not in trunk as far as I know.
I'd like to keep the patches separate, if you have an impro
Hi
Mark, great work on implementing the extended types.
As for this problem, I don't see it. With a simple style that
only includes one line type with overlays it works just fine. Same
with relations.
Also looking at the code change, there is nothing that appears to
touch that area of the styli
Hi
> I guess I found out that
> --description
> does not work when using a "-c template-file". Is this a bug or a
> feature, i.e. does the source need to be patched or should I patch the
> documentation? (I'm willing to do the latter, but not if a fix in the
> source is really easy).
It works as
Hi
> In the patch, this solution is applied when the number
> of points is less than 32.
>
> Is that an exactly determined number, or is it
> just a rough estimate of where things start to go wrong?
I think the problem might be that the polygon splitting goes wrong
when the lines touch. Only lar
On 08/21/2009 09:26 AM, Morten Kjeldgaard wrote:
> The default version of mkgmap distributed with Ubuntu 9.04 (jaunty) is
> svn630. I tried upgrading to version svn1067 which has recently appeared
> in Debian unstable, but now I get a Java heap space exception on the
> _same_ .osm file that worke
Hi
The sea polygon patch uses a feature from java 1.6 (NavigableSet),
whereas mkgmap is currently released for java 1.5. Perhaps there
is a different way to do it that avoids the use, but it could be
time to consider going to 1.6.
Now I don't personally mind going to 1.6 and in fact I announced
Hi
On 08/22/2009 02:00 AM, Morten Kjeldgaard wrote:
> I've tried at 512M, 1024M, all the way up to 4096M, with the same
> result. The only difference is at 4G it takes much longer before
> mkgmap gives up. I don't think there's much point in going further
> than 4G, the problem must lie elsewhere.
Hi
> I will follow up when I have investigated the large memory usage of
> the Danish tiles. Anyone else have problems?
The reason for the high memory usage is that most nodes in the Danish
extract look like this:
All those tags take up the memory. Before relation suppor
On 08/22/2009 12:48 PM, Chris Miller wrote:
> I guess the problem is if you just compile with 1.6 and run on 1.5, the VM
> fails pretty quickly with a UnsupportedClassVersionError. Perhaps if you
> set and checking
> immediately
> on startup to see if eg NavigableSet exists you'll be able to d
Hi
> But I do understand what you are saying. Does anyone else have an
> opinion about this?
Perhaps it belongs in the splitter doc then? Or the splitter
could leave out (or comment out) the description lines
by default, unless the --description option is given.
..Steve
___
Hi
On 25/08/09 23:18, Simon Josefsson wrote:
> In building other java applications, I'm used to checking that the build
> is sane by invoking 'ant test'. This fails for me with mkgmap. Is this
> a known problem, or something I can fix?
You need to have junit in you classpath (or edit build.xml
Hi
On 25/08/09 22:46, Christian Gawron wrote:
> This version of the patch fixes a bug in the previous version which
> caused tiles with no shoreline to be "flooded".
I've separated out the sea generation from the multipolygon
patches and applied them to the multipolygon branch.
It would be great
Hi Christian
> Can you send me the tile causing the problem or provide me a download link?
http://www.mkgmap.org.uk/tmp/63240014.osm.gz
It also takes 30min to compile. There is a lot of coastline
there of course.
..Steve
___
mkgmap-dev mailing list
Hi
> L> the tiles rendered with Mkgmap. The red tiles in Denmark are caused
> L> by all the house numbers which cause the guesstimate mechanism
> L> (--max-nodes) of splitter to be fooled in thinking that Mkgmap could
> L> produce working maps for those areas. Splitter should be more
> L> in
Hi
> Actually the problem was the org.hamcrest package. If anyone else runs
> into the same, I solved it by installing the "libhamcrest-java" debian
> package and then fixing up the installation like this:
That is strange, those classes are in my junit-4.5.jar and I thought
that it was direct
Hi
> style-file: "../mkgmap/resources/styles/mystyle"
> mkgmap silently fails and applies the default style.
>
> Why does it bork on the ""? How would it cope if you had Windows-like
> spaces in your path to the style file? It would *really* help if
> someone could add a quick patch to make sur
On 27/08/09 17:50, Robert Joop wrote:
> steve, the resources/help/en/options file states that the --tdbfile
> makes mkgmap write a .tdb file.
> but i always got a .tdb file, even though i never used this option.
> is this option only necessary when one merges .img files, and
> superfluous when pro
Hi
> But really what I'm more interesting in is where mkgmap's
> transliteration database comes from. Knowing that will help with
> further contributions. There's a lot more that can be done than just
> improving row03.trans. That was just a sample improvement that I
> needed at that time.
The te
Hi
On 30/08/09 16:12, Felix Hartmann wrote:
> Just as a note for people so you don't wonder why something does not
> work: Rules of the follwing type *& ( !=* | !=* ) will not work. and
> instead allways be enacted. So for example both of the follwing rules
They do work, its just that the secon
Hi
> oh so my logic was wrong. I would have thought that the above would not
> show in case both mtb AND bicycle route is set, and not OR.
> So how would I do that, a rule that needs all three to be true like
> this: ( tunnel=yes & route!=mtb & route!= bicycle ) [] ?
Yes, that would be true
Hi
On 31/08/09 14:51, frmas wrote:
> The following styles are available:
> arvernes 1.0: Style for OSM Maps
> contours 1.0: Style for OSM Maps
> default1.0: Style for OSM Maps
> noname 1.0: Style for OSM Maps
> perso 1.0: Style for OSM Maps
Hi
As an aside, I always planned to have lists of values which might
be useful in this case. Eg. the following
> #set mkgmap_surface values to either paved or unpaved
> highway=*& surface=asphalt {set mkgmap_surface=paved ...
> highway=*& surface=cobblestone {set mkgmap_surface=paved
On 01/09/09 17:36, Torsten Leistikow wrote:
> Moin,
>
> I have to admit, that I have didn't quite understand the processing of
> the action part of the style rules, when I made the first verwion of the
> patch. And I also have to admit, that I still do not really understand
> it. But nevertheless
Hi Chris
> Where to from here? As some of you may have guessed, this new splitter is
Here are a few ideas based on things that we discovered with earlier
versions of the splitter.
* Avoid pathalogical behaviour at the poles by limiting latitude to +- 85.
* Split tiles that are larger than a gi
On 03/09/09 14:49, Chris Miller wrote:
> L> And are (large) polygons that span many tiles fully supported?
>
> The splitter has been able to handle relations that span an unlimited number
> of tiles since r49, and ways that span many tiles since r60 or so. As far
I'm not sure if this what Lambe
1 - 100 of 1862 matches
Mail list logo
