home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / bit / listserv / dbasel / 1435 < prev    next >
Encoding:
Internet Message Format  |  1993-01-11  |  2.9 KB
  1. Path: sparky!uunet!munnari.oz.au!bunyip.cc.uq.oz.au!topaz.ucq.edu.au!leovacd
  2. From: leovacd@topaz.ucq.edu.au
  3. Newsgroups: bit.listserv.dbase-l
  4. Subject: Re: spatial data in Clipper
  5. Message-ID: <1993Jan11.141319.13184@topaz.ucq.edu.au>
  6. Date: 11 Jan 93 14:13:18 AET
  7. Organization: University of Central Queensland, Australia
  8. Lines: 62
  9.  
  10. >Date:         Wed, 6 Jan 1993 09:06:00 LCL
  11. >From:         PaussaVC@SSD0.LAAFB.AF.MIL
  12. >Subject:      spatial data in Clipper
  13. >>> My problem is how to improve the performance of point data
  14. retrieval
  15. >>> Expected ratio points/total points is i.e. 5/100000.
  16. >>> in a test dbf of 10E5 records.
  17. >>> D.Leovac@ucq.edu.au
  18.  
  19. >>Gino,  For a database of 100,000 records, you should be using Oracle
  20. >>instead of dBase files.  Purchase Oracle, SQL*Net and ClipDbBridge
  21. >>301-330-9621 (There is another Clip-Ora package out of England - Call
  22. >>Nantucket)
  23. >>On a network, you can use Oracle/os2 or Oracle/Unix depending on how
  24. >>much power you need. On a network, you can then split the workload
  25. >>between the client doing user interface and calculations and the
  26. >>server doing record retrieval.
  27. >>-Chuck
  28.  
  29. >You should actually be using FoxPro.  Oracle requires too high an
  30. >overhead in hardware, time and $.  FoxPro runs on '286s and up and
  31. >incorporates a strong subset of SQL with the XBase language that you
  32. >are already familiar with.  No, it doesn't yet support client/server,
  33. >but neither does
  34. >Clipper (I think).
  35.  
  36. Dear colleagues,
  37.  
  38. Thank you very much for your response. The information which I received
  39. are very useful, but my main problem was not the tool itself - it's the
  40. efficient way of retrieving the spatial data. So it's better to explain
  41. it a little bit more.
  42.  
  43. 10E5 records contain 2D coordinates of point data <p_id; x; y>. The aim
  44. is to retrieve small subset of data contained in a desired recatngular
  45. area.
  46. Example:
  47. - coordinates are defined as relative numbers in area 1 x 1, so typical
  48.   record is like this: < Point 1, 0.43211843, 0.73919484 >,
  49. - there is an area ( described by 2 sets of point coordinates [( x1,y1)
  50.   and ( x2,y2)] ) which contains some of the points in a database. The
  51.   area is very small comparing to the total area.
  52.  
  53. How to get points from that area when using XBase?
  54.  
  55. I have used index file < key: str(x)+str(y)> and softseek, but the
  56. results are pore - to much time is needed. For desired area of 1/25000
  57. and 5 points in it, it took approx. 30 sec on 486 machine.
  58.  
  59. Slightly better results are achieved when the point data are clustered
  60. into the 'cells'. Computing time is reduced due to testing whole
  61. cluster of data represented by cell coordintes rather than inspecting
  62. every particular point coordinate.
  63.  
  64. i.e. index key is [ substr(x,3,3) + substr(y,3,3) + str(x) + str(y)]
  65. so the key value for this point < Point 1, 0.43211843, 0.73919484 > is
  66. { 432 739 0.43211843 0.73919484} what means that this point belongs to
  67. the cell (432,739).
  68.  
  69. Anybody has a similar problem?
  70.  
  71. Gino
  72.