A coverted ozi map seems completely off-calibration :-(

[InfX]

I've tried converting some ozi maps into tar files, supposedly identical to the ones resulted by following this manual. Locus is able to show the maps, yet the calibrations is totally off,to an extent i kinda suppose it is not even being read. For example Bat Yam location on this map, checked by scrolling to it and long-tapping on it is approx N1.479xE1.153, while in reality its more like N32.019xE34.744 !!!

I am attaching the offending .map (rar-ed, the forum wont let me attach .map as it is), please help if possible.

Thanks.

[Menion]

hmm map is on WGS84 ellipsoid and UTM coordiante system so it should work fine in Locus. Can you upload somewhere just some small map for testing? Map file you attached, is fine but I cannot find problem with just this file ...

[InfX]

Fetch it directly from me, here - //http://inf.homeip.net/tmp/pub/map/. It's a box sitting on my home internet connection, that is rather slow. Sorry about that, i just don't have any "proper" hosting anywhere. I can upload to rapidshare or some similar "wait until our timer ticks down and watch our ads" service, if fetching directly from me is a problem.

The "10_DEST2195.ozfx3" is the original map.
The "10_DEST2195_ozf.map" is it's calibration file, the very same one attached here.
The "10_DEST2195_ozf.tar" is the tiled png + tar-ed version with the .map inside.

Some notes:
* The ozfx3 + map work just fine on Oziexplorer 3.96.2a (that's what i happened to have installed on my PC) and looks properly calibrated (tested by applying recorded tracks on it)
* The ozfx3 + map work fine with Androzic without any conversion whatsoever and seems properly calibrated (tested by simply turning the GPS on in Androzic and walking around a bit)
* I did not use the provided java image splitter to tile+tar the images and map (but i don't see why would it matter)
* The tar-ed map opens just fine on Locus, but nowhere near properly calibrated
* Same happens with a bunch of similar ozi maps (yet they all originate from the same source)

[Menion]

hmm I discovered source of troubles. It's because map file contain coordinates for calibrated points directly in UTM system, but I don't use correct recompute mechanism. There is missing zone number so I have to compute by myself in app (what I don't do now). If you can, try to use WGS coordinates in map file (just for test), this should work good now ...

[Menion]

hmm looks that I need some help here InfX!

I don't know well map format of ozi so I need some light on it please ... (or any other guy)

this is your map file!
OziExplorer Map Data File Version 2.2
10_dest2195.tif
C:Documents and Settingshp nc6230DesktopMaps OZI GPS10_DEST2195.ozfx3
1 ,Map Code,
Israeli,WGS 84,   0.0000,   0.0000,WGS 84
Reserved 1
Reserved 2
Magnetic Variation,,,E
Map Projection,Transverse Mercator,PolyCal,No,AutoCalOnly,No,BSBUseWPX,No
Point01,xy, 2560,  536,in, deg,    ,        ,N,    ,        ,W, grid,   ,     115000,    1170000,N
Point02,xy, 8443,  514,in, deg,    ,        ,N,    ,        ,W, grid,   ,     140000,    1170000,N
Point03,xy, 8477,12289,in, deg,    ,        ,N,    ,        ,W, grid,   ,     140000,    1120000,N
Point04,xy, 2602,12299,in, deg,    ,        ,N,    ,        ,W, grid,   ,     115000,    1120000,N
Point05,xy, 4221, 3591,in, deg,    ,        ,N,    ,        ,W, grid,   ,     122000,    1157000,N
Point06,xy, 7515, 3575,in, deg,    ,        ,N,    ,        ,W, grid,   ,     136000,    1157000,N
Point07,xy, 7538,10172,in, deg,    ,        ,N,    ,        ,W, grid,   ,     136000,    1129000,N
Point08,xy, 4245,10178,in, deg,    ,        ,N,    ,        ,W, grid,   ,     122000,    1129000,N
Point09,xy, 6114, 7108,in, deg,    ,        ,N,    ,        ,W, grid,   ,     130000,    1142000,N
Point10,xy,     ,     ,in, deg,    ,        ,,    ,        ,, grid,   ,           ,           ,
...
Projection Setup,    31.734090000,    35.212060000,     1.000000000,       170251.00,      1126868.00,,,,,
Map Feature = MF ; Map Comment = MC     These follow if they exist
Track File = TF      These follow if they exist
Moving Map Parameters = MM?    These follow if they exist
MM0,Yes
MMPNUM,4
MMPXY,1,210,203
MMPXY,2,9031,164
MMPXY,3,9072,13228
MMPXY,4,261,13256
MMPLL,1,  34.520539,  32.134085
MMPLL,2,  34.917989,  32.136140
MMPLL,3,  34.919460,  31.635609
MMPLL,4,  34.524600,  31.634007
MM1B,4.250598
MOP,Map Open Position,0,0
IWH,Map Image Width/Height,9224,13454

and my problem is to get correct coordinates for calibrating. In point01 - point09 section are only UTM coordinates which are very weird (point somewhere into africa). I'm sure I need update them to correct values, which after transformation into spherical, looks similar to bottom MMPLL coordinates. There is line "Projection Setup" that contain some coordinates but that not help me much.

here is simple convertor http://home.hiwaay.net/~taylorc/toolbox ... eoutm.html but I cannot get similar coordinates to bottom once. Any help is really needed! Thanks

EDIT: hmm I just discovered nice site ... http://www.rus-roads.ru/gps/help_ozi/ma ... ormat.html, this should help me, so wait

[InfX]

First off all, thanks for trying to fix this. Sorry, but i don't know a thing about the .map files structure in ozi, i see you've found a site that describes it, though. The calibration points coords are most likely relative to the Israeli datum used in the Israeli Transverse Mercator grid, i am assuming this because (1) that's how they look like, (2) the original scanned map is ITM, (3) "Israeli,WGS 84, 0.0000, 0.0000,WGS 84" - this "Israeli" should mean something, what else can it possibly mean. And yea, i know it also says "WGS 84", don't ask, no idea what those params are

[cseu]

Yes well there is something weird about this calibration anyway... the projection is set to transverse mercator so yes i would assume the native map projection is ITM...
However :
— The parameters of the projection are the ones of the ICS grid ( http://www.mapi.gov.il/geodesy/ics_ftp.txt ) and not ITM ( http://www.mapi.gov.il/geodesy/itm_ftp.txt ) which is not a transverse mercator projection but a cassini soldner. Maybe it doesn't matter that much on a 1:50k scale thats why the map seems to be ok when opened in GE (a little bit shifted though).
— The calibration points coords appears to be in the old israeli datum (in black on the map) if the map is ITM it should use the red ones, which seem to be from the new israeli datum... but then again the two datums are used in the same grid... i wish i could read hebrew, especially the red square in the legend which seem to talk about the new and old israeli datums.

Bottom line, apart from reprojecting the map to google mercator (that's what i would do) maybe recalibrate the map using the UTM grid (in blue) or try the datum shift fields in the map file but i don't know how Ozi handles those particular settings, here are some conversions parameters : http://www.eye4software.com/products/co ... datum/195/

Maybe the best solution is to generate new maps from the Israeli map source in locus because those maps seems to be quite old anyway.

Cheers,

Cseu.

EDIT : i had the same off calibration problem trying to convert some UTM maps with ED50 datum... i think that if you map is not already in the google mercator projection you will encounter problems... you can to use MapTiler ( viewtopic.php?f=10&t=334&p=1425#p1425 ), MAPC2MAPC (viewtopic.php?f=10&t=413 ) or Global Mapper ( viewtopic.php?f=13&t=280&p=1107#p1107 ) instead of imagecutter if the datum shift solution is a dead end. (those 3 solutions will allow you to reproject the map to google mercator WGS84 before slicing it.

[Menion]

guys you have just count that Locus allow use TAR maps, but I needed only Mercator maps in WGS84 datum, nothing more, so other map projections and datums aren't implemented in Locus. I'll work on it slowly because this is not one of priorities in Locus ... but I'll try

[InfX]

i wish i could read hebrew, especially the red square in the legend which seem to talk about the new and old israeli datums.

Ill have to dissapoint you here, all they say in that square is "the new grid is in red, the old grid is in black, the new grid is an improvement over the old one because its a mercator grid (keeps the angles), here is a conversion formula, old to new". Obviously, they use some nicer wording.

BTW, my current conclusion - if you have an already calibrated ozi map - use androzic, dont bother converting. If you want to download a piece of online map on the go (at the nearest wifi) - use locus.

[Menion]

yes agree. Locus is not since begin created with purpose of ozfx maps. I'll release new version today but expect that nothing change to better. I'll have to work on it later, so as InFX wrote, use Androizic for these maps rather then converting into Locus, because here is actually not any simple solution for this.

[InfX]

guys you have just count that Locus allow use TAR maps, but I needed only Mercator maps in WGS84 datum, nothing more, so other map projections and datums aren't implemented in Locus. I'll work on it slowly because this is not one of priorities in Locus ... but I'll try

Well, this makes it quite useless for such a maps, because most often ozi maps are calibrated by the local grid, simply because the local one is the main grid on the map, while ozi supports all of them anyway.

Manual recalculation of the calibration points for all the map files ? Maybe if i had no alternative, but right now, no thanks.

[cseu]

Ill have to dissapoint you here, all they say in that square is "the new grid is in red, the old grid is in black, the new grid is an improvement over the old one because its a mercator grid (keeps the angles), here is a conversion formula, old to new". Obviously, they use some nicer wording.

Ah ok I see, thanks.

Anyway, the global mapper process i've detailed in one of my post is quite easy and a great way to batch render thousands of OZF maps of all kind into one single sqlitedb (or several, considering the 2GB android limitation), the problematic and not very user friendly task is only the second part when you have to assemble the tile folders into a sqlitedb... this feature will be implemented in a future version of MAPC2MAPC which will make the process much easier. I will try to ask a feature request to MOBAC to support OSM tile folders as an input, it would be fantastic.