Hi, that's spatial indexing (using quadtrees or whatever). It mostly involves a binary search in a tree. This can be applied in a plain ACCESS structure (though not really relevant), or as an OLE object by itself, as far as storage is concerned.
A simple implementation (at least the one I'm using when designing such things, and I'm not an expert at this ...) is to store point information in a table, define an index based on a quadtree traversal (think of it as a vectorized index or as a hash table key), use this index to build geometry against. In no way I would redefine a complete file layout on adding or deleting points. Using a static Quadtree structure (ahum ... that leads to defining a minimal resolution according to some 'bounds' closes, like MI) the overall point adressing is straight forward (just keep the original coords if you like !). Using a dynamic quadtree is more time consuming at use (one must update the structure on each point addition or deletion), but let you without resolution problems and is much more memory efficient. Points spatial indexes can be used fast to set the display state of each object (only by looking at the first components of the point indexes). All this handling is no more than computer operations on indexes, it does only adress file data layout to some extent (you don't even need the actual points/nodes positions when using a fixed static quadtree : the position *is* the index !). Or am I completeply wrong about the way MI adresses such issues ? I just don't know how the products you're speaking about are handling spatial indexing (not even how MI does!). For sure, this is a point of strength for any GIS product, and what I describe here can very certainly be tuned for speed. And those tunings would certainly not be made public ... by MI for example. And I guess this is the main reason for speed inconsistencies (as well as the drawing engine (MI 's not bad at this), the database access type (I won't beat a ~dead horse, but consider that accessing external data from within MI and outside MI *leads!...* to speed inconsistencies ! and if MI treats 'foreign' geometry like it does with 'foreign' data, then ...) Eric. > -----Message d'origine----- > De : Bob Young - www.bydesignwales.demon.co.uk > [mailto:[EMAIL PROTECTED]] > Envoy� : jeudi 25 octobre 2001 14:44 > � : Eric > Cc : Mats Elfstrom; Robert Crossley; MapInfo List > Objet : MI-L MapPoint 2002 now supports MapInfo TAB and ESRI SHAPE files > > > Dear Eric > > Whilst I would agree that keeping the data in Access gives advantages, I > am not convinced that keeping the object in an OLE object is an > improvement. > > The MAP file is equally compact, in that objects can be stored as > variable length. However in addition the data is organised into blocks > that are spatially adjacent. > > Whilst it is possible to index the OLE objects in Access two objects > that are physically next to one another on the ground will not be next > to one another in the Access file. > > In the MAP file data is constantly reordered so that actual storage of > data is adjacent. Therefore when you zoom to an area on the screen the > heads on your hard disk are not jumping all over the place. > > I am aware of some recent comparisons between SQL Spatialware, Oracle > Spatialware and MapInfo native that shows data can be retrieved and > drawn much quicker from the TAB ( MAP ) file. The MAP file still has a > lot of life left in it yet ! > > > > Regards > > > Bob > By Design > > > > > In message <[EMAIL PROTECTED]>, Eric > <[EMAIL PROTECTED]> writes > >Geomedia among others ... the concept isn't new. But still, > light years in > >front of MI data management concepts. > >No matter how the geometric information is stored, Access OLE > objects make > >everything more compact, that's all. The real difference comes with data > >management, querying and relationships ! GIS are *not* painting apps ! > >I, for myself, decided long ago now to keep data in Access, > while using MI > >for managing geometry. It'll even enable to design -easyly- friendly user > >interfaces ! > >Eric. > > > >> -----Message d'origine----- > >> De : [EMAIL PROTECTED] > >> [mailto:[EMAIL PROTECTED]]De la part de Mats > >> Elfstrom > >> Envoye : mardi 23 octobre 2001 23:57 > >> A : Robert Crossley > >> Cc : MapInfo List > >> Objet : Re: MI-L MapPoint 2002 now supports MapInfo TAB and ESRI SHAPE > >> files > >> > >> > >> Robert Crossley wrote: > >> > For a start, they have stored the spatial object as an OLE > >> object within the Access table. The concept is very neat, > >> > >> Hi All! > >> > >> Forgive me if I jump to conclusions here, but didn't Geomedia buy that > >> concept a few years ago? > >> The idea does not seem all that new to me. > >> > >> Regards, Mats.E > >> -- > >> ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: > >> :Email/ [EMAIL PROTECTED] ICQ#9517386 : > >> :---------------------------------------------------------------------: > >> :Mail/ GISKRAFT, Mats Elfstroem, Vaepplingv 21, SE-227 38 LUND, SWEDEN: > >> :Phones: +46 46 145959, +46 70 595 3935 : > >> ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: > >> > >> > >> > >> _______________________________________________________________________ > >> List hosting provided by Directions Magazine | www.directionsmag.com | > >> To unsubscribe, send e-mail to [EMAIL PROTECTED] and > >> put "unsubscribe MapInfo-L" in the message body. > > > > > > > >_______________________________________________________________________ > >List hosting provided by Directions Magazine | www.directionsmag.com | > >To unsubscribe, send e-mail to [EMAIL PROTECTED] and > >put "unsubscribe MapInfo-L" in the message body. > > -- > Bob Young - www.bydesignwales.demon.co.uk _______________________________________________________________________ List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, send e-mail to [EMAIL PROTECTED] and put "unsubscribe MapInfo-L" in the message body.
