I think this is just one of those cases, where you notice that Garmin
map format simply does not allow to create a map that is useful for
several usage cases. Better use a dedicated cycle-map (in which you
would delete the oneway information in case of cycleway=opposite or
similar).
Mark
In Austria I still had problems. But the number of errors was reduced
from around 25 to 10. For those roads with errors, Either someone has
corrected them online (after noticing the error messages) or some are
still broken. I will keep track of this. The 15 roads that produced no
more errors
Working great. Autria.osm.bz2 from Geofabrik compiles without any
unroutable roads now. I checked some that with 1049 still would not
route and they do route.
Quick Distance also working without problems - though speed improvement
only up to 40% (but hey that's a lot too, after your reports I
Hello, I wanted to patch
/trunk/src/uk/me/parabola/mkgmap/reader/osm/xml/Osm5XmlHandler.java to
map oneway attributes to 'highway=oneway1' adapting the code that was
used for the cycleway opposite patch.
Attached is what I added but it does not work. Can someone find the
mistake or my
I think this has not yet been mentioned on the mailing-list:
There seems to be some code missing in the road-name-pois. I changed the
ID to several values that if used inside the Points file, would be
findable with the search function. If however I use the same ID for the
-road-name-pois
I assume there is a serious bug in the austria.osm.bz2 currently.
See here the error output. It compiles 3 out of 7 tiles correctly, and
then chokes on the 4. tile.
I'm sure there is an error in the country extract (with the same command
all other country extracts of europe compiled fine - the
. all marine points don't show up on my
Vista HCx, others are not really stylable via typfile.
Thilo Hannemann wrote:
Hi Felix,
Am 03.06.2009 um 12:06 schrieb Felix Hartmann:
Is it possible to encode arbitrary maxspeed values or can we only set
in steps of 10km/h?
For example having road
1. See here:
http://www.openstreetmap.org/edit?lat=48.084294lon=16.296498zoom=18
Have a look at the street running paralell to the railwaylines (name
Thomas-Tamussino-Straße, ref B11).
Mappers have nicely and correctly entered the bridge. The section after
the bridge is only about 3m long,
What about deleting the following lines, what is the reason?
ferry.equals(currentWay.getTag(route {
AND
long cyclwayId = currentWay.getId() + CYCLWAY_ID_OFFSET;
Will enabling the --make-opposite-cycleways now overwrite the underlying
road?
Mark Burton wrote:
Hi Marco,
I've
Sorry, just wanted to say that I had misinterpreted tortoiseSVN diff
files. I though those lines were deleted, but it only showed differences
to my version. I just wondered why (which was falsely assumed by me) the
lines were deleted.
I do change the maps by using the following command in my
Hallo,
Sorry Mark for probably bugging you again
First the probably easier question, why is it not possible to use a line
like
1.
highway=* source=plan.at [0x07 resolution 24] in my style file? The
point in plan.at throws an exception.
2.
highway:plan.at=* .
Same problem.
In
Let's hear them. I got many many complaints that my maps don't
recalculate...
How can I change 0x110301 so that it sets 1,4,23 instead of 1,3,17?
Mark Burton wrote:
Hi Felix,
I found out the problem associated to route recalculation not working
(well working but only far too late). We
O.k. so there must be another reason.
Maybe its as well related to road_speed or road_class?
(Garmin may think that the lower the road_speed the higher the chance
that there are buildings that obstruct GPS reception, or the lower the
accuracy of the maps, cause minor roads are not that well
Yeah getting that 3byte field to work would be splendid. There are so
many lines that one can't differentiate without it. Especially as
Maspource only displays half as many compared to the gps.
Mark Burton wrote:
Felix,
O.k. so there must be another reason.
Maybe its as well related to
Well that is intended behavior, nothing wrong. Mapsource over the road,
GPS under the road. You should not make the road to wide in typfile,
otherwise it will be difficult to identify. I don't think one can change
this (and in case, I would rather have the opposite, namely have the
route under
It is not for me, depends on the 0x** , and of course only for lines and
POI. Polygons have to be defined in typfile.
2009/6/30 Thilo Hannemann thann...@gmx.de
Has anybody had success controlling the drawing order with the
--preserve-element-order option?
The drawing order is random for me,
No, I allways use typfiles. google typfile editors (either maptk or the
online typfile editor) and change it.
Marco Certelli wrote:
--- Mer 1/7/09, Tomas Straupis tomasstrau...@gmail.com ha scritto:
2009/7/1 Felix Hartmann extremecar...@googlemail.com:
Drawing order on GPS:
1
2009/7/7 Ralf Kleineisel r...@kleineisel.de
On 07/06/2009 12:57 AM, svn commit wrote:
--dem-increment Verical distance between the contour lines (default is
10m).
I have a suggestion here:
Currently I use SRTM2OSM to make the contour layers. I use two different
styles to make two SRTM
2009/7/7 Torsten Leistikow de_m...@gmx.de
Steve Ratcliffe schrieb:
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
2009/7/18 Garvan maew garvan.m...@online.com.kh
Did anyone else notice this problem before? Were you able to reproduce
it? If it helps, I can prepare a map that will have a routing problem
just at the edge (there's a biking tunnel that MapSource avoids, no
matter how hard I try, while
This is again overview map fault. Simply create bigger overview map, and it
will work
2009/7/18 maning sambale emmanuel.samb...@gmail.com
Here's areas.list result from splitter
# List of areas
# Generated Mon Jul 13 21:55:45 PHT 2009
#
63240001: 215040,5447680 to 600064,5754880
# :
Is there a big speed difference when using your patches?
I currently have quite some difficulties running extensive checks, as I can
only create maps via remote desktop.
Principally I think many people await this feature.
2009/7/19 Torsten Leistikow de_m...@gmx.de
Moin,
finally I got my
Torsten Leistikow wrote:
Felix Hartmann schrieb:
Is there a big speed difference when using your patches?
I haven't noticed any significant difference, but I haven't done any
real comparison measurements.
It certainly depends on the number of additionally created elements, but
I think
Yeah, merging roads if possible would be great. Even more important
would however be smoothing of curves. i.e. make serpentine corners on
mountain streets more smooth, because otherwise if there is a say 160°
corner, it will add a big time penalty, which in a car is more or less
correct, but on a
I still think the solution is to make the overview map bigger and
place cities or similar with name mkgmap in 2 opposite corners
around 500m larger than the actual map.
At least this works if I compile the overview map with maptk.
On 27/07/2009, Valentijn Sessink valen...@blub.net wrote:
Hello
Some of you have already made patches for the name so maybe you know
whether the following would be feasible.
Currently add or set name will delete everything and put in the new
text. the start-with used by Thilo's patches works AFAIK (I never tried
it) also only following highway=* [0x??
Yeah that's true, but how to do it better?
I would think a name-file where you can run rules for name, info
sections , phone numbers, etc. seperate from the style-file would be
best. Currently of my lines style-file which consists of 8.000 lines,
7.000 are basically only to get proper naming,
Torsten Leistikow wrote:
Mark Burton schrieb:
This is not a comment on your proposed scheme but I do believe that the
current handling of name and ref (and the highway shields, etc.) is
completely fucked up. IMHO, munging the element name and its refs
together in the style file is completely
Mark Burton wrote:
Ahoy there shipmates,
This patch is a first stab at providing support for the 3-byte extended
types that are used on marine maps.
Is this patch only for marine types (think -- I have to put my gps into
marine mode) or also for any mode, and shown by typfile as used by
Hi Mark, I still don't really understand the advantage.
1. maxres, can we really specify this, I was not aware that this is
possible.
2. So the only advantage is that it is shorter to tpye and that
preprocessing becomes possible?
thanks for clarifying a bit here
Felix
2009/8/6 Mark Burton
2009/8/7 Steve Ratcliffe st...@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
How comes that the newest mkgmap versions write in information into the
last level, instead of leaving it empty?
I do think that this prohibits using layers in Mapsource as maps without
empty level seem to show up allways on top, instead according to their
mapname/mapid. 3 weeks ago this
I bet you used --ignore-osm-bounds option on compiling!
Carlos Dávila wrote:
Yesterday I realized I can no longer calculate routes involving more
than one tile in Mapsource using my Spain map. I compile it daily using
latest svn and I don't know when the problem was introduced (it worked
Chris Miller wrote:
Hi Valentijn,
Chris Miller schreef:
but my impression is that the conclusion was that the splitter should
be rounding areas off to boundaries in multiples of 4096 rather than
2048?
As far as I've seen - thanks to Steve Ratcliffe's findings - divisible
by
It does work, you have to set all 3: series-name (mapset name in Mapsource),
family-name (mapset name on GPS), description -- name for the individual map
tiles - the only of the three that is written directly to the individual
tiles, the both other are written to tdb/overview image.
2009/8/13
2009/8/13 Mark Burton ma...@ordern.com
v4
I have gone back to the original ordering of doing short arc removal
before clipping as the previous version of this patch badly broke
polygons
As for arcs whose length is less 5m, I am not convinced they are
actually a problem as far as routing
work another way - Felix Hartmann commented
that I need to set three naming options, I did not try that yet (and I
am a bit puzzled by it - if you don't set all three, the description
option doesn't do anything???)
So it's the Nuvi map naming that I'm after.
it's --family-name that you want
2009/8/16 Chris Miller chris.mil...@kbcfp.com
FH You would need to find an old metroguide europe map. They were
FH notlocked...
I thought they weren't routable either though?
They were routable in Mapsource, and with a little trick (should be floating
around in the gps forums) one could
frmas wrote:
Hello,
Now according to the latest firmware, we no longer have to create a
gmapsupp.img file to get multiple maps.
I created multiple maps (data downloaded from geofabrik), and put them
on the SD card.
The first one (Auvergne or Massif Central) is one I bought.
germany (just
svn commit wrote:
Version 1140 was commited by markb on 2009-08-19 10:00:27 +0100 (Wed, 19 Aug
2009)
Added support for extended types.
These are sometimes called '3-byte types' but the upper 8 bits of the
type is not encoded in the map objects (just the lower 16 bits) so any
non-zero
Mark Burton wrote:
That list is in my eyes just crap when it comes to extended types, as
any of those lines / points / polygons will only be shown if defined in
typfile, and many others if defined too. I only don't know whether there
are any regions that will not be shown, or only shown in
Nop wrote:
Hi!
Paul schrieb:
Unless you already have data for Srtm2Osm then this approach will not
work as NASA has moved the data and Srtm2Osm is no longer being updated.
This is no longer true. Bomm has taken over and updated srtm2osm, it is
working again and I am currently even
Torsten Leistikow wrote:
Moin,
finally I got my eclipse environment running and was able to build
mkgmap from source. So the next step was my first extension of mkgmap.
Until now a single OSM element was converted into a single garmin
element, i.e. the first one in the style file with the
Thilo Hannemann wrote:
Am 19.08.2009 um 22:17 schrieb Simon Josefsson:
How do I use the test-map:all-elements feature?
(I have a problem with highway=service roads on my Legend HCx when it
uses Swedish, it labels the roads as Allé which I suspect is a
mis-translation of Alley -- solving
2009/8/21 Mark Burton ma...@ordern.com
Hi Felix,
Is this still a problem or did it get better?
Cheers,
Mark
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
No I'm still unable
2009/8/21 Mark Burton ma...@ordern.com
Felix,
No I'm still unable to get routes and overlays to show up on the map.
either using 1140 with multiple elements patch (no other patches), nor
with
clean svn version.
That's sad.
I don't know what you mean by routes or overlays so I
Using the same style-file as before but changing many streets from 0x??
into 0xe10?? I needed to reduce by 70-75% the maxnodes settings of the
map so that it compiles without error.
Is there possibly a bug or is it normal that using extended types forces
you to use much smaller tiles?
Anyone
Mark Burton wrote:
Looks like the extended type stuff has triggered an ancient bug.
Please try attached patch and see if you can process bigger maps again.
Yeah that patch solved it! Great.
I think you can commit it, as otherwise extended types become kinda
troublesome to use.
I think the condition precedent you're thinking about is wrong here.
The name that shows up in the routing does not have to be the street
that is routed on. At least I see that behaviour quite frequently. How
can I be sure? I use many non routable overlays and they have different
naming.
It's nothing special. They are using standard garmin tools AFAICanTell. They
learned from our maps that proper bicycle/topo maps will only provide good
routing if preference is given in general for bicycleroutes.
The autorouting is pretty good for cyclists, however because of 2 reasons:
1. their
you don't give enough details.
has each layer it's own map id?
BTW EACH layer that is supposed to look different needs it's own TYPfile
(does not have to be different, but for each mapID the name (up to 8
characters no more) of the typfile must be different).
If you use gmaptool to create
family-id needs to be different for each layer, otherwise transparent
cannot work. each needs it's own tdb and so on too. transparent and draw
priority works ONLY for mapsets, not for single maps.
frmas wrote:
Felix Hartmann a écrit :
Hello Felix,
you don't give enough details.
has each
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
match even though neither route=mtb nor route=bicycle is set:
tunnel=yes ( route!=mtb
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 is
fine in this
Ralf Kleineisel wrote:
Felix Hartmann wrote:
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
Steve Ratcliffe wrote:
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
Steve Ratcliffe wrote:
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 ) [] ?
svn commit wrote:
Version 1159 was commited by steve on 2009-08-30 22:51:15 +0100 (Sun, 30 Aug
2009)
Make the not operator in a style file
actually work.
great, it was not working at all before. I just noticed now.
Now it seems pretty good. (I still have some problems but I think it's
gmaptool can readout the key which is used for your unit from the gmapsupp.
Gert Münzel wrote:
Hi, Steve,
Can I install my genuine .IMG file as an installed map?
I think so but i guess this breacks copyrights law.
I guess you have a CityNavigator on your streetpilot.
If it's on a
started selling Garmin devices, he was pushed heavily to also sell
certain amounts of Garmin maps. The shop owner wanted to be able to
advice independently so he stopped selling the devices.
Felix Hartmann wrote:
It's nothing special. They are using standard garmin tools AFAICanTell
Chris Miller wrote:
I've just chatted to Steve about this and it turns out my description below
is incorrect. What really matters is the resolution of the overview map,
NOT the resolution of the lowest zoom level you're using.
overview map is at 15 AFAIK, are you sure it's 16?
Anyhow
Steve Ratcliffe wrote:
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
*a)
*First of all Mapsource =6.14.1 is not affected. Problem exists on
=6.13.7. And my Vista HCx crashes on trying to zoom into this map and
restarts. (this is after a master reset, so it's the map not the GPS). I
do assume that Nuvi and other modern units will take the maps without
crashing.
Mark Burton wrote:
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.
yes I have via -ea
Really great,
what we would need now is a possibitlity to split by countries.
e.g. taking europe.osm.bz2 and splitting it into all major states, this
would avoid having to use the tiles from geofabrik which cannot be
merged without having broken routing at the frontiers.
Has anyone any idea
No it did not fix it.
However I think the bug lies elsewhere. I think mkgmap is putting too
much information into one tile/small area (even though total tilesize is
only 7.4MB).
Following on the tries from yesterday I found several possibilities to
not have the bug:
1. delete the first half
Felix Hartmann wrote:
Mark Burton wrote:
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
Mark Burton wrote:
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=*
2009/9/3 Mark Burton ma...@ordern.com
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
2009/9/3 Mark Burton ma...@ordern.com
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
Mark Burton wrote:
This v2 patch makes squarer subdivisions than v1 - otherwise works
the same.
Well, on v1 patch, the problem at this place appeared even without
having the problematic polygons in the polygons file.
With v2 it's back to normal and only happens with the problematic
Apollinaris Schoell wrote:
On 5 Sep 2009, at 9:15 , Steve Ratcliffe wrote:
Hi Mark
On 05/09/09 11:44, Mark Burton wrote:
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
Mark Burton wrote:
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.70079lon=16.18152zoom=16layers=B000FTF.
I have attached a
Mark Burton wrote:
Hi Felix,
Please try the attached patch on the original tile and see if it fixes
the problem.
Cheers,
Mark
___
mkgmap-dev mailing list
Mark Burton wrote:
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
Mark Burton wrote:
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
Mapsource only uses even resolution. Only gps uses uneven. So as you did
not set 20, that might be the reason to go straight up to 22. Try with
even resolution only.
MarkS wrote:
I've battled trying to narrow this down for a couple of days.
I have a lines style file that contains:
Hi,
1. I think reversing ways with oneway=-1 is run before parsing the
stylefile. Could it be changed to run afterwards, or else make it
possible to give a command in style-file to change direction of way?
Reason being, is that I intend to make steep streets oneway in the
downhill direction:
The incline tag can be defined with the following units. The following
has all the same meaning:
incline=100
incline=100%
incline=45°
default is assumed to be %.
Now in the style-file having a line checking for
incline90
will catch both
incline=100 and incline=100%
but not
incline=45°
It is
Thanks a lot for your immediate reply and work.
Working great.
I think this should be added to trunk, because other people might find
it useful too. (it's pretty strange if you can delete oneway=* in the
style-file, but you can't change the direction of a street).
Mark Burton wrote:
Please
Johann Gail wrote:
neither splitter or osmosis insert new points. but it is required to
have boundary nodes in mkgmap. splitter would need to calculate
crossing points with the boundary or a provided split polygon with all
ways and insert the boundary points.
This is my opinion too.
it stands for New Technology, a format that is foremost used by Garmin
City Navigator / CN maps and I think some other Road maps. Not
compatible with very old (say older 3-4 years) Garmin GPS.
Nakor wrote:
Hello,
Excuse my ignorance here but what does NT stand for?
Thanks,
N.
Mark Burton wrote:
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
svn commit wrote:
Version 1216 was commited by markb on 2009-09-22 10:40:17 +0100 (Tue, 22 Sep
2009)
Added ability to display bounding boxes of route centres.
For diagnostic/development purposes, it's now possible to display the
bounding boxes of the route centres by using:
Mark Burton wrote:
Felix,
Where TYPE is the Garmin line type to use (decimal, not hex).
The option parsing code doesn't seem to know about hex so it only works
with decimal types. A pain, but I can't be bothered to do anything
about it.
Mark
So instead of 0x27 I would have
Mark Burton wrote:
Thanks to those who have tried yesterday's table A patch. Seems like it
hasn't caused any problems (so far).
After playing around a bit on my Vista HCx I did notice slightly
different routing too. The maximum distance that it manages without
route calculation error did
Valentijn Sessink wrote:
Valentijn Sessink schreef:
given the turning penalties Garmin seems to have. But the Nuvi does
really really strange things: it routes me through
... by bicycle (I forgot to mention that.).
forget bicycle mode. Only car / taxi and similar modes work well.
Chris-Hein Lunkhusen wrote:
Hi,
I have some issue at the position 51.123 / 7.19:
http://img34.imageshack.us/img34/9803/bild1zh.png
I see this on my own map and on Lambertus' OSM routable.
In this area multipolygons are used very heavily.
Don't know if that could cause this error.
svn commit wrote:
Version 1235 was commited by steve on 2009-09-27 16:42:08 +0100 (Sun, 27 Sep
2009)
BRANCH: style
Fix hang on continue action.
Thanks for your work, sadly though for me at the moment the style branch
is useless because continue on the strictly ordered style rules has
Steve Ratcliffe wrote:
On 27/09/09 21:28, Felix Hartmann wrote:
Thanks for your work, sadly though for me at the moment the style branch
is useless because continue on the strictly ordered style rules has no
effect. (I need to have the rules running not only in order, but also if
continue
Mark Burton wrote:
Felix,
Additionaly It would be great, if the road-name-pois option could be
dropped
Just don't use it. Seriously, it was only intended to be a quick and
dirty way of being able to search for streets. When the global search
stuff matures it will almost certainly
Latin1 is only producing Questionmarks instead of greek symbols. Which
Codepage does one have to use for Greece?
Anyone got a clue?
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Torsten Leistikow wrote:
Moin,
I am not sure, I understand plans completely.
Felix Hartmann schrieb:
I have a: highway=path; route=mtb; mtb:scale=0: mtb:scale:uphill=0
mtb:scale=0 mtb:scale:uphill=0 route=mtb { name 'mtbrt00 ${name}' |
'mtbrt00' } continue
mtb:scale:uphill=0 route
svn commit wrote:
Version 1246 was commited by steve on 2009-09-30 10:54:40 +0100 (Wed, 30 Sep
2009)
BRANCH: mdr
Impelent mdr 4 and 9 as best as we know.
The unknown byte in mdr4 is set to a constant, we still don't know what
it is there for. Plenty of things appear to work still.
In general the continue patch works great. However the continue patch
does not seems to drop stuff if mkgmap later on thinks it is identical??
After messing for 3 hours now trying to find out why some actions don't
work I have found out that mkgmap does not enact the continue action,
in case it
svn commit wrote:
Version 1249 was commited by steve on 2009-10-01 23:44:14 +0100 (Thu, 01 Oct
2009)
BRANCH: mdr
Points are numbered across both the point sections and not separately.
This caused all points in subdivisions that had an indexed points section to
be incorrect.
Searching
svn commit wrote:
Version 1253 was commited by steve on 2009-10-02 19:35:23 +0100 (Fri, 02 Oct
2009)
BRANCH: mdr
Added mdr 5 for cites.
The city field in all points that are themselves cities is set.
You should now see on a city search the region and country if set.
Not implemented
maning sambale wrote:
using the latest mdr branch
time java -Xmx1512m -jar
/home/maning/osm/routable_garmin/mkgmap/mdr/dist/mkgmap.jar
--code-page=1252 --ea --tdbfile --latin1 --country-abbr=PHI
--country-name=PHILIPPINES --remove-short-arcs=5 --route
--road-name-pois --add-pois-to-areas
svn commit wrote:
Version 1261 was commited by steve on 2009-10-05 16:04:55 +0100 (Mon, 05 Oct
2009)
BRANCH: mdr
Implement the reverse index.
Do you think about putting in a switch, or reversing index only for
--gmapsupp?
Before it was working alright in Mapsource and on GPS (if
Steve Ratcliffe wrote:
On 05/10/09 22:40, Felix Hartmann wrote:
Do you think about putting in a switch, or reversing index only for
--gmapsupp?
Before it was working alright in Mapsource and on GPS (if transferred
via Mapsource) - wasn't it?
No it didn't work before - the gmapsupp
1 - 100 of 1591 matches
Mail list logo
