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
______________________________________________________________________
