Hi Tim
The parameters for the projection are held in the
header of the MAP file.
As mentioned before I do not know MITAB, but I
would imagine there is a function to read the projection for any particular
table. If there is not Uffe has really good documentation at his website on
the content of the MAP file so you could read the parameters directly
yourself.
The overhead of conversion is not a problem with
regard to render times. Bear in mind you are not reprojecting the whole file,
only what you render, and the time to transform a node is much smaller than
the time to read the data off the disc or storage card. Ideally though the
OSTN02 "look up" table wants to be loaded into memory once, so that it is
constanly used from memory. Even if it isn't you'll probably find the
Operating System will cache it, giving the same effect.
You can see from MapInfo that the "on the fly"
transformation will not be a problem. MapInfo is continually doing this as the
contents of all its MAP files are actually in integers, and need to be
multiplied by a "step size" which are the widths and heights of the Bounds
clause divided by 2 GB to get floating point values. Its doing even more when
different layers are in different base projections or even just different
Bounds clauses.
Regards
Bob
----- Original Message -----
Sent: Wednesday, August 16, 2006 3:29
PM
Subject: RE: [mitab] Locating features
in a particular area
Hi
Bob,
Thanks for your reply, it was very helpful :P
I
sort of imagined it would work something like that. I didn't know seamless
layers could be recursive!
I'll only be dealing with raster seamless layers. Another problem I
have is coordinate conversion so I can project features on the
screen.
At
present I make sure all my vector data is WGS84-lat/long, but I might have
some OS mastermap data that I need to convert from UK grid to WGS84 for
display.
I
have a free coord conversion library, but I don't know the best way to work
out what projection and datum is being used in the vector or raster tabs,
and how I would realte this to the datums and projections in the conversion
library. I guess I'll just have to have a look up table and test it
well.
If
map data is in a different datum to the one I want to project on the screen,
I wonder how much overhead there is in converting each point to another
datum, especially when there might be hundreds of points on the
screen.
Cheers
Tim
Hi Tim
The seamless table has a normal table at its
root. So the MAP file for the seamless table contains region objects that
represent the MBR extents of each base table. Its a similar concept to the
spatial index within the MAP file and allows vector layers to exceed the 2
GB limit as well as allowing rendering of multiple rasters.
I have not used MITAB. However if you can
render regions from a MapInfo table, and you can render a single raster
table then you should be able to render the seamless as well.
You will need to read from the base table all
the MBRs that intersect your area of interest. This is the same as reading
all the regions that intersect your area of interest in a normal vector
table. Having done this use the record number to read into the DAT file to
get the Table name. This is similar to the technique needed to be able to
thematically render where again you need to read the DAT record to be able
to decide the render style based on attribution. I assume MITAB allows you
to retrieve from the DAT file, but if it doesn't they are fixed length
records, and the structure is defined both at the top of the DAT file and
within the TAB file.
Now you have the table name you can read the
TAB file for each raster so that you can render the raster in the
appropriate position - the same as you would for a single
image.
To render a seamless vector table you need to
make your code recursive so that you can step down through possibly more
than one level but I would have expected your seamless raster to only be
one level deep ie the base table points directly to the raster
tables.
If you need more guidance feel free to get in
touch.
Hope this answer doesnt take 12 hours to
reach you. Having assumed the last message was not making it - after no
activity for 12 hours - I posted a second and as you probably saw they
both arrived virtually together!
Regards
Bob
----- Original Message -----
Sent: Wednesday, August 16, 2006
1:14 PM
Subject: RE: [mitab] Locating
features in a particular area
Hi Bob,
Thanks for the info.
I worked how to use the spatial index in MITAB. I just need
to add raster map rendering now. One problem I have is reading a
seamless raster tab - I don't think seamless layers are supported
in MITAB, and I don't know the format to create my own
reader.
Cheers
Tim
Hi Tim
A very late reply to your query on mitab on 5 June
this year regarding
finding features in an area:
To speed
up access of your maps of Europe reduce the number of tables by
combining them to best use the performance of RTREE spatial
index.
The index is already built for you - in the MAP file. It
is implemented as
documented in several text books. Basically you
only load a percentage of
the file.
The deeper the tree the
more impressive the performance is. As already
answered through
MapInfo L we have implemented a 64 bit version and the
performance
is still just as fast. I parameterised the code so that I
could
test different block sizes etc and tested against National
Coverage of
MasterMap.
Typically each parent has ten to
twenty children ( depending on object type
and MBR resolution), so
for just one extra disc read the MAP file can be ten
to twenty
times bigger, for two reads one hundred to four hundred
times
bigger and so on. The trick is to keep the tree balanced as
you add objects
to it.
Limit with 64 bit pointers in ID (
instead of 32 bit ) is 16 Terrabytes.
MapInfo do not think there is
a need for this now that Oracle Spatial is so
popular, but did take
a look at the work we did. We have had virtually zero
interest in
what we did on 64 bit format from customers so perhaps they
were
right not to commit programming time to it, and now many
public sector
organisations are implementing storage in
Oracle.
I find it incredibly frustrating that so much money is
spent on Oracle to
store data when it can be stored for free using
MapInfos elegant native
solution - and can actually be written and
retrieved significantly faster.
Missed your original postings
in June. Hope this belated answer, and the
MapInfo L one is
relevant for you.
Cheers
Bob
----- Original
Message -----
From: "scumhampton" <[EMAIL PROTECTED]com>
To:
<[EMAIL PROTECTED]com>
Sent:
Monday, June 05, 2006 9:59 AM
Subject: [mitab] Locating features in
a particular area
> Hi,
>
> I have to say I'm
really impressed with mitab.
>
> I'm creating my own map
renderer - much like MapX. Primarily I will
> use Navteq Street
data.
>
> The problem I have is with large data sets.
Currently my application
> loads an entire layer into ram at the
start (e.g. minor roads). This
> is not a problem for
Luxembourg, but when I load the whole of Europe
> into ram, as
you can imagine, things start to become an issue.
>
> I
know loading all the data at once is not the right thing to do -
I
> only need to load the area that I am currenly displaying.
But how?
> How do I find the ID of the features that should be
displayed? I
> guess I need some sort of geospatial look-up
table. How does MapInfo
> do it - it must load from the file
dynamically as you pan. Is this
> possible with mitab - or would
I need to create my own special look-
> up
table?
>
> Any help would be appreciated.
>
>
Kind regards
>
>
Tim
>
>
>
>
>
>
>
>
>
>
>
Yahoo! Groups
Links
>
>
>
>
>
>
>
______________________________________________________________________
This
email has been scanned by the MessageLabs Email Security
System.
For more information please visit
http://www.messagelabs.com/email
______________________________________________________________________
______________________________________________________________________
This
email has been scanned by the MessageLabs Email Security System.
For
more information please visit http://www.messagelabs.com/email
______________________________________________________________________
