Hi Marko,
> I successfully tested it on Finland with Edge 705 firmware 2.90. The map
> is slightly smaller (36 megabytes instead of 37) and routing (car and bicycle,
> 200 to 250 km distance) still works. It still makes a stupid detour for
> the bicycle route, but I would blame that on the Garm
Reduce number of Table A entries.
Previously, Table A entries were unique for each combination of start node,
end node and RoadDef. But no information from the start and end nodes goes
into Table A so we can ignore the start and end nodes and all roads
within a given routing c
Hi Chris,
> Ah yeah, it's not very clever I'm afraid, that looks like a bug :( I'll
> fix it later this afternoon, but in the meantime it looks like you'll have
> to put the zip file in the current directory (or hack the code yourself).
No problem.
> Another thing, I'd recommend against usi
Hi Chris,
> - Tiles can be named based on the area they cover. To use this, download
> one of the cities files from http://download.geonames.org/export/dump/ and
> point to it with --geonames-file=cities.zip. The splitter will then
> try to name each tile sensibly based on the biggest city in
I tried processing great_britain.osm with the --generate-sea option and
found the following issues:
1 - it generated lots of warnings like this:
2009/09/17 10:40:26 WARNING (Osm5XmlHandler): Way null (OSM id
4611686018427388109) has short arc (0.00m) - but it can't be removed because
both en
Nop,
Please try 1197 and see if the problem is still there.
Mark
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hello Nop,
> mkgmap r1196 quits with an error "polygon offset too large". When I use
> mkgmap r1163 with exactly the same data and parameters, no error occurs.
>
> What does this message mean?
It means that the change I made could have been better. I will
investigate.
Mark
___
> In principle, it should be quite possible to route across tiles that
> have a wiggly boundary. This could be achieved quite straightforwardly
> by the splitter tagging the boundary points so that mkgmap knows where
> they are.
The attached patch is possibly all you need in mkgmap to be able to
> I seem to remember someone mentioning that Garmin supports non-rectangular
> map tiles. Would that help? Or would it be too much effort with too little
> gain to implement that in mkgmap (and splitter)?
I have seen a Garmin map with boundary points that do not lie on a
rectangle so, it's pla
> Yes even although the advice to use final is frequently seen on the
> internet 'for performance' it is not really true. And if it were you
> would be better to make the class final anyway.
Why's that?
Mark
___
mkgmap-dev mailing list
mkgmap-dev@list
Hi Chris,
> As far as I'm aware, declaring a method final doesn't make a whole lot of
> difference to hotspot these days. Hotspot can still inline a method if it's
> not declared final but determines at runtime it's not overriden elsewhere.
> If some new code eventually turns up that does over
Steve,
> > Why zap the final? It was there for a reason.
>
> And what would that reason be?
It explicitly declares that the method can never be redefined and
therefore is a candidate for inline expansion.
Obviously, the method is implicitly final anyway due to it being
private but adding the
Hi Steve,
- private final void incArcCount(Map map, Coord p, int
inc) {
+ private void incArcCount(Map map, Coord p, int inc) {
Why zap the final? It was there for a reason.
Cheers,
Mark
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgma
Please try attached patch.
diff --git a/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java b/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java
index c45f2d9..c5f5bde 100644
--- a/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java
+++ b/src/uk/me/parabola/mkgmap/osmstyle/StyledConv
Hi Felix,
> Some remarks about the merge lines concept, and the reasoning why it
> will not help much and needs to be extended/changed.
Your remarks are most interesting. I have been considering writing some
code to tweak the arc headings to help make the routing directions more
sensible. In m
Hi Thilo,
> I will modify the code that the merging is applied even earlier.
> Shouldn't be too hard to do.
Did you do that? I would be keen to try a version because I notice on
my first few trips with the Nuvi that sometimes it says "keep
right/left" when it should say "turn right/left". I th
Hi Paul,
> I've just updated to the latest mkgmap from trunk and am now having
> problems processing tiles that I have previously successfully processed.
> The error I am receiving is
>
> java.lang.IllegalStateException: Polygon offset too large
Please try attached patch.
Cheers,
Mark
diff -
Hi Felix,
> I can't believe that it works. We don't even have the data in
> Openstreetmap (in general), nor anything about lanes in the style-file.
http://www.malsingmaps.com/forums/viewtopic.php?f=73&t=16364&start=0
Obviously, we don't know how to encode this stuff at the moment.
> Probab
Hi Maning,
> One user reported that "lane assist" works on my mkgmap generated map.
> I don't know what lane assist do and not so sure if it works with
> mkgmap. Anybody here can confirm that this works for newer garmin
> nuvis?
I have a brand new Nuvi 255 and it doesn't have "lane assist" but
Hi Chris,
> I was just wondering that OpenRouteService.org was able to route
> over such a spot.
The fact that other routing services choose to do that does not make me
any more enthusiastic about the idea.
Cheers,
Mark
___
mkgmap-dev mailing list
mk
Hi Chris,m
> >> does mkgmap auto-merge points which have exactly the same coords?
> >>
> >> I though the remove-short-arcs option would do this, but last week
> >> I found a routing problem on a netherland motorway which
> >> was caused by such a double node and the map was created
> >> with the
Hi David,
> Max_RGN_SIZE and MAX_NUM_LINES increased confidently make possible to
> build my huge contour lines polish format file. Thank you for this change.
I suspect it was actually "Take into account the fact that lines can be
split when counting them." that made the difference. Whatever, I
Committed a bunch of stuff that improves subdivision generation and
removal of short arcs that reach tile boundaries. I've tested it all on
GB, NL and PH? tile sets with no problems.
Apologies in advance if they break anything.
Cheers,
Mark
___
mkgmap
Hi Chris,
> does mkgmap auto-merge points which have exactly the same coords?
>
> I though the remove-short-arcs option would do this, but last week
> I found a routing problem on a netherland motorway which
> was caused by such a double node and the map was created
> with the remove-short-arcs.
Maning,
> wohoo! routing works. The merging of points is a good solution. Does
> this affect only the nodes along the clipped line?
It affects all nodes that need merging to avoid a short arc being
created. Any connected nodes whose separation is less than the
specified distance (5m in your ca
Hi Maning,
Thanks for the files.
I have found the problem that was stopping the new code from working as
expected (it was an old bug in the line clipping code).
So, please test the new patch. I have tried it myself on your data
files and it works OK as long as you give --remove-short-arcs=5. If
Hi Maning,
> Same routing problem. The problematic segment is approx 6 meters
That's a shame, I had great hopes for the patch.
It would be useful if I had the OSM files for the two tiles in
question. Can you please zip them up (gzip or zip) and either email
them to me or make them available on
Hi Maning,
I had an inspiration!
Contrary to my last message, I think we can probably do something
about this. Please try the attached patch on the same OSM data as
before and see if the routing changes (hopefully, for the better).
Use the same options as before.
It's based upon my previous at
Hi Maning,
> I encountered routing across tiles again.
> Using mkgmap ver 1163 and splitter r83.
>
> This photo shows routing detours to the cemetery when I used a split file:
> http://farm3.static.flickr.com/2593/3892530364_d80a7546b4_o.png
>
> But no problems when no split file was used:
> ht
Felix,
> I was all the time using it without problems. I don't know whether there
> have been improvements, but nothing became worse in any case. I
> subjectively think map panning got a tiny bit quicker, but might be
> mistaken.
Ok, good.
If the patch is working right, it should be reduci
> Yeah great, Finally fixed.
> I could not find any errors in the map.
That's good.
The problem was that a polygon was being generated that only
contained 2 points. The more recent mapsource versions must
ignore degenerate polygons (and lines as well, presumably) but the
older mapsource and at l
Hi Felix,
Please try the attached patch on the original tile and see if it fixes
the problem.
Cheers,
Mark
diff --git a/src/uk/me/parabola/imgfmt/app/trergn/LinePreparer.java b/src/uk/me/parabola/imgfmt/app/trergn/LinePreparer.java
index 122d811..9fb07a2 100644
--- a/src/uk/me/parabola/imgfmt/a
Hi Felix,
> thanks for your work,
You're welcome.
> by now I am sure (100%) which polygon was fucking up (as so far as being
> the main cause). It's the forest here:
> http://www.openstreetmap.org/?lat=47.70079&lon=16.18152&zoom=16&layers=B000FTF.
>
> I have attached a screenshot of it' r
Playing with my shiny new Nuvi 255, I notice that it can route across
an OSM map of the UK pretty well. It can find long routes
reasonably quickly. In comparison, mapsource 6.13.6 often fails to
determine a route at all and when it does it is rather slow about it.
Do other people see good routing
Hi Maning,
> Apologies if this is a stupid question. What is the benefit of
> creating poi index? for search?
That's not a stupid question at all. The POI index sounds like it
should help with searching for POIs and maybe it does but, at this
time, it appears to make no difference to the searc
Felix,
Wild guess here: I wondered if the POI index was overflowing and
trashing some other stuff because in the bad map example you sent, it
contained just over 32K entries. So commit 1170 disables POI index
generation. It wasn't useful anyway, so that's no loss. Please see if
that makes any di
In trying to determine the cause of the problem that Felix has reported
when tiles use a lot of polygon styles, I have been looking at the code
that divides areas into "subdivisions". The attached patch (applies to
1170) makes a few changes in that department. It is not expected to fix
the polygon
Ahh, you're adding POIs to areas, aren't you. Have you tried building
with that option turned off?
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi,
I got my Nuvi (a 255) and the OSM map looks good and appears to route
OK.
I thought I would use the road name pois but the default type code that
gets used (0x640a) doesn't appear in the POI search on the Nuvi - so
are there any Nuvi users using RNPs? If so, what type code are you
using?
Ch
Hi Felix,
> Ups, sorry, here is the output using logging.properties:
>
> again broken vs not broken
OK, thanks for those. They are interesting because they differ less
than I expected but in an unexpected way (work that one out!)
I want to double check so please apply v3 of patch (attached)
Felix,
> Okay, here are the output files. Once including the problematic
> landuse=* line, once without.
Thanks. Unfortunately, they have too much other crap in them and not
enough of what I want to see. Did you use the logging.properties file I
sent to you?
Mark
__
Felix,
Please enable info logging by using the attached logging.properties file
and add this to the java options (note - it's a java option not a
mkgmap option)
-Dlog.config=logging.properties
rerun with v2 of the patch and email me the mkgmap.log file(s). They
should contain some diagnostic ou
Felix,
> Well, on v1 patch, the problem at this place appeared even without
> having the "problematic polygons" in the polygons file.
That's interesting.
> With v2 it's back to normal and only happens with the "problematic
> polygons" or without deleting a fair bit of my lines in the lines
Hi Gert,
> >What I can see on my etrex is that the custom icon will disappear at
> >the level you expect (given the resolution value it has) but some of the
> >built in poi icons disappear sooner.
> Which type ?
Umm, can't remember exactly what I tried but I think it was 0x1b16
(lighted navaid,
This v2 patch makes "squarer" subdivisions than v1 - otherwise works
the same.
diff --git a/src/uk/me/parabola/imgfmt/app/trergn/RGNFile.java b/src/uk/me/parabola/imgfmt/app/trergn/RGNFile.java
index f0300e8..5c0dc77 100644
--- a/src/uk/me/parabola/imgfmt/app/trergn/RGNFile.java
+++ b/src/uk/me/pa
Hi Felix,
> Well one thing that this patch makes, is much much bigger filesize
> (around 30% increase).
To be expected.
> Furthermore it really crashes Mapsource. Not even possible to move out
> anymore.
Hmm, not so expected.
> After panning around a bit and choosing a well working zoomscal
Hi Felix,
Well, I don't have much to offer at this time regarding this problem.
Given that the issue has gone away in recent versions of mapsource, it
makes me think that it is a bug/feature/limitation in the garmin code
which they have subsequently fixed.
Obviously, we want your map to work w
Hi Gert,
> Hi, Mark
> >So what's going on? Are custom pois treated differently with regard to
> >zoom levels?
>
> AFIAK i would say no.
> For me it seems more like that the pois in general will be treaten different,
> e.g. settelements will be shown longer by zooming out than other pois though
Felix,
> Well, as a "developper" I would recommend using 6.13.6. 6.13.6 behaves more
> or less like the GPS.
OK - I grabbed a copy of 6.13.6 and can now see it blowing up when I am
zoomed between 3k and 15k and I try to display the northern region of
that map.
I don't know what the issue is her
Felix,
It does look odd around:
http://www.openstreetmap.org/?lat=47.605&lon=15.638&zoom=11
but that's how the OSM data is.
Mark
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Felix,
> If you are on medium detail between 1km and 3km (resolution 20) there is a
> small area where if you pan either nothing happens (screen not refreshing),
> or you can not see the roads. With 1165 routing is not broken anymore, so I
> think that patch solved something. Simply set detail t
Felix,
> 2. there is also a mapsource installation in the subfolder, just install
> by doubleclicking (with admin rights) install_openmtbmap_at.bat
> Or create a gmapsupp with gmaptool for your gps by doubleclicking on
> create_gmapsupp.bat
I installed the AT map into mapsource and can view it
Felix,
> I don't think this will help, I have found tiles (i.e. Vienna where more
> 77 different polygons and 74 line tpyes are used in one tile) and those
> tiles work perfectly fine. Should I even give it a try?
No, it was just a guess.
Mark
___
Felix,
> 3. delete 1/3 of the lines in my polygons style-file or delete this last
> section:
> leisure=* & fixme!=yes & import!=*[0x2a
> resolution 24]
> tourism=* & fixme!=yes & import!=*[0x2b
> resolution 24]
> sport=* & fixme!=yes &
Hi Felix,
> No it did not fix it.
That's disappointing.
> Please find here:
> http://openmtbmap.org/downloads/mkgmap_overload_bug.zip (22MB)
I will look at that this evening.
BTW - you didn't confirm that you have assertions enabled.
Also, can you split the tile into two to reduce the amoun
Hi Felix,
Just committed a bug fix that could be relevant. Please see if 1165
behaves any differently.
Cheers,
Mark
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi,
I thought I would make myself a traffic light icon using the TYP file.
The icons appear where you expect but they are visible at higher
zoom levels than the built in icons for pois that have the same
resolution.
I tried a few different type codes without noticing any obvious
difference.
So
Hi Valentijn,
> Just one small remark (at the moment you have probably ordered your Nuvi
> already): if you're going to use it on a (motor)bike, you might want to
> check the availability of a mounting kit for it.
Actually, it's for car use only because I already have an etrex vista
hcx which I
Thanks to everyone who has responded to my question - I have read all
the replies.
As I want the Nuvi primarily for navigation, I don't really mind if
logging isn't possible or, if possible, not good quality. The
fact that it works well with our maps is enough.
Cheers,
Mark
Something like a 255W, perhaps. Anyone got any experience with this
unit or similar?
Thanks,
Mark
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Martin,
> Is there any chance for this patch to get committed in the near
> future? I think it would be very helpful for routing (also with
> barrier=cycle_barrier/gate/lift_gate etc) and the case of target
> and/or destination being too close to the barrier is not that common.
>
> Thank you
Hi,
Thinking about purchasing a Nuvi. What models work well with mkgmap
maps?
Also, do any provide a track log facility so I can use the same gps to
collect data?
Cheers,
Mark
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgm
> This is reporting a bug in the "fixed" error reporting (introduced
> in rev 1153). I have committed a "fixed fix" but even if that does the
> right thing, you will still get an exception reported because there
> must be something else going wrong for there to be an exception that
> needs reporti
Hi Gianmario,
This is reporting a bug in the "fixed" error reporting (introduced
in rev 1153). I have committed a "fixed fix" but even if that does the
right thing, you will still get an exception reported because there
must be something else going wrong for there to be an exception that
needs re
Hi Ralf,
> My TYP works on my eTrex Legend HCx which is very similar.
Could you please email that typ file to me?
Also, what levels are you using?
Cheers,
Mark
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailm
Hi Mark,
> However, I seem to recall that when I first played around with this the
> background reverted to yellow quite early on as I zoomed out. In the end
> this problem went away when I reduced the number of levels in my style
> file - originally I was using the default style which seemed
Hi Michael,
> --ignore-osm-bounds
If you ignore the bounds, the ways don't end at the same coordinates.
Cheers,
Mark
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Felix,
> Have you tried a master reset on the vista hcx? maybe you switched of
> showing polygons (that's possible via one of the sub-menus)?
Is it possible?
> I have attached you a supersmall map as gmapsupp.img, is it also yellow?
> (please zoom in to closer than 2km). Simply unpack and
I've had zero success in setting the background colour on the etrex. I
can happily change styles of lines and polygons so the type file is
working to a degree.
Has anyone managed to change the background colour on an etrex vista
hcx?
Thanks
___
mkgmap-
Hi Felix,
> You can simply download a small country from my website, both thin??.TYP
> and white??.TYP have white background set.
>
> http:///openmtbmap.org/download
>
> and try it out and look for differences.
Err, I can't read that archive format, please just email me a TYP file.
Cheers,
Hi Felix.
> Strange, try to look in gpsmapedit what polygon is used for background.
> Have you patched it to 0x4a, i have seen some people doing that (though
> I don't know what for)?
No, it's still 0x4b.
> drawing level 0, and make sure no other is on 0 or it might be displayed
> behind th
Hi Felix,
> yes, simply set background polygon 0x4b to a color (if using maptk watch
> out to set one pixel to something else, because usually if you go for a
> single color only maptk will put second color transparent and
> performance sucks, this is a bug in maptk, the online typfile editor
Hi,
Just playing around with TYP files and wondered if it is possible to
change the "Garmin yellow" background to anything else using a TYP file?
If not, is there any other way of doing that?
Cheers,
Mark
___
mkgmap-dev mailing list
mkgmap-dev@lists.
Hi Gert,
On Sun, 30 Aug 2009 17:00:33 +0200
Gert Münzel wrote:
> Hi, Mark
>
> >>/ But i discovered that neither the flashing nor the morsing works in
> />>/ Mapsource or in my 60csx . I guess these functions are only avaiable
> />>/ with special marine gps of Garmin.
> /Sorry, my statement
Hi Gert,
> i just build mkgmap out of svn trunk and test it with a single
> marine/ext poi in an mp-file.
> It works.
Good.
> But i discovered that neither the flashing nor the morsing works in
> Mapsource or in my 60csx . I guess these functions are only avaiable
> with special marine gps
Hi Gert,
> I just run a small test.
> r1155 you commited now seems to work fine with polish format datafiles and
> extended Garmin types.
Good.
> Upcoming commited version of extended types + attributes i will test after it
> is available.
I shall commit that stuff soon as although it proba
Valentijn,
> I was thinking: are the oneway street and the fake route interconnected
> automatically? I know they share the nodes, is that the same as being
> able to skip between them?
>
> I.e. is it:
>
> | |
> +--++-++ a street
> +--++-++---
Hi Garvan,
> I spent some time testing short arcs and managed to find some routing
> problems where mapsource will route in one direction but not in the
> reverse direction. This looks like a mapsource bug to me, so I am
> curious if it is seen with all versions of mapsource, or even if others
Hi Gert,
> Thanks for this very fast help.
You're welcome.
> Though i'm able to build a version from svn, i will wait for the snapshot for
> testing it.
OK.
> >I shall work on the extended type attributes so that they are usable
> >from mp files using the syntax described in the cgpsmapper
Gert,
> >I just took a quick look at the code and I can't see why extended types
> >are not acceptable in mp files. Please post the error message you got.
>
> Ok. here it is.
>
> D:\GPS\mkgmap-r1152>java -Xmx512m -jar mkgmap.jar -c wkr_options.txt *.mp
> SCHWERWIEGEND (Main): java.util.concurre
On Fri, 28 Aug 2009 14:11:41 +0100 (BST)
svn commit wrote:
>
> Version 1153 was commited by steve on 2009-08-28 14:11:41 +0100 (Fri, 28 Aug
> 2009)
>
> Fix error reporting.
>
> Normal errors that are detected by mkgmap should just be printed but since
> multithreading was added, all errors d
Valentijn,
> I've tried a couple of different methods to build opposite-cycleways,
> namely forbid all motoring traffic, make a real cycleway, but all of
> them make the Garmin turn to the last part of the oneway Hembrugstraat.
> So I conclude it's a Garmin issue. I'm sure we could come up with a
>
> 3,295898,45,791016
>
> Looks like a decimal point vs. comma problem.
new Formatter(Locale.ENGLISH).format(...) ?
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi,
> While looking into the make-cycleway-code, I notice that a simple tag
> with "cycleway=lane" (or equivalent) would be enough to make a cycleway.
> However, if there's no access restriction for cyclists, there's no real
> need to build an extra way here - or is there?
You have a point. Of c
Hi Maning,
> Several problems with Search by Address in Garmin Mobile XT reported
> by some of my users.
>
> " - unable to search for road names via Address Search option using
> Where to?" -> "Addresses"
> -Step 1 0f 5 in Address Search requires entry of "State", no state is
> listed and no mat
Hi V,
Yes, using mapsource, if the cycleway=opposite tag is present it will
route a car into the last segment of Hembrugstraat using the cycleway
but if the destination is not the last segment of that road or the
cycleway tag is not present, it will route the car correctly.
Experimentally, I spl
Hi Gert,
I just took a quick look at the code and I can't see why extended types
are not acceptable in mp files. Please post the error message you got.
The extended type attributes are not yet supported for mp files but I
will look at implementing that.
Cheers,
Mark
___
Hi Gert,
> Hi, guys
> first time with a prebuild version r1152 i tried to use this extended
> type in an overlay.
> Unfortunately i got an error message from mkgmap.( i can provide it if
> needed but i guess it doesn't).
> Input file was in polish-format.
> Could it be that the polish format re
Hi Valentijn,
> First, a remark. Since the oneway=yes/cycleway=opposite roads have
> "(cycleway)" attached to their names, a GPS unit will randomly show
> either the regular name, or the (cycleway) name. Which isn't too bad for
> testing, I'd suggest you leave it this way until we're set and done
Hi,
> If I understand you correctly, your v4 patch is in svn now, so if I run
> into strange routing, I should report and/or check if v5 performs any
> better?
No, only a portion of the v4 patch has been committed because it's a
useful fix to have independently of whether the rest of the patch i
v5
in case people are still using this patch, i have reissued it without
the stuff that is now in commit 1152.
if you are using this patch and think it should also be committed -
please say - it didn't seem conclusive that is was useful when we last
discussed it
-
v4
I have
> Ok, I tried a different button in svn and now got a patch relative 1143
> only. Is this one better usable?
Yes, it applies to 1148 OK and builds OK.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/
Spotted the problem, some of the patch is relative to 1143 and some of
it relative to 1148. Don't know how you managed that. Perhaps an svn
wizard can help.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/list
Hi Torsten,
> And please let me know, whether the attached patch is usable, since this
> is my first generated patch. I simply asked svn for the differences
> between my local copy and the head version.
I haven't tried the patch but a quick look shows that it attempts to
add some stuff that is a
v5 - added support for facility (point type 0x010903) and also now
catches and reports exceptions incurred during processing of attributes.
A facility point can have a mkgmap:xt-facilities attribute which is a
bitmask made from these values:
0x01 boat ramp
0x02 drinking water
Mark,
> I'll change it. The original intention was to avoid creating another
> option (as I'd seen some comment about "yet another option"). But I'm
> happy to go down that route.
Personally, i'd rather see a new option added than an old option
obscured!
Also, if we introduce a new option to
Hi Mark,
Thanks for the contribution - it sounds like a good idea.
One thought, how about using words and not numbers, words are easier to
interpret when you come back to them 3 months (5 minutes?) later. So
you could have something like:
ignore-maxspeeds (same meaning as now for compatibility
Furthermore, should isClosed() require the way to have at least 3
points? Otherwise, the enclosed area is going to be very thin!
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
I notice that isClosed() uses equals() (the points have the
same coords) but I think it should use == (the points are the same
object).
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Looks like the extended type stuff has triggered an ancient bug.
Please try attached patch and see if you can process bigger maps again.
diff --git a/src/uk/me/parabola/imgfmt/app/BufferedImgFileWriter.java b/src/uk/me/parabola/imgfmt/app/BufferedImgFileWriter.java
index 37d5509..b1d6fb2 100644
601 - 700 of 986 matches
Mail list logo
