MAILS 6.7 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146
  1. From green@superliminal.com Fri Jul 19 02:55:40 2002
  2. Return-Path: <green@superliminal.com>
  3. Received: from camelot.itc.it (camelot [195.223.171.5])
  4. by orchestra.itc.it (8.11.6/8.11.6) with ESMTP id g6J0uQa24233
  5. for <blazek@itc.it>; Fri, 19 Jul 2002 02:56:26 +0200
  6. Received: from jareth.dreamhost.com (jareth.dreamhost.com [66.33.198.201])
  7. by camelot.itc.it (8.11.3/8.11.3) with ESMTP id g6J0uOn13308
  8. for <blazek@itc.it>; Fri, 19 Jul 2002 02:56:25 +0200 (MET DST)
  9. Received: from superliminal.com (adsl-63-201-35-131.dsl.snfc21.pacbell.net [63.201.35.131])
  10. by jareth.dreamhost.com (Postfix) with ESMTP
  11. id 39D616B5EA; Thu, 18 Jul 2002 17:56:22 -0700 (PDT)
  12. Message-ID: <3D37638C.7AEB82AE@superliminal.com>
  13. Date: Thu, 18 Jul 2002 17:55:40 -0700
  14. From: green@superliminal.com
  15. Reply-To: green@superliminal.com
  16. Organization: Superliminal Software
  17. X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U)
  18. X-Accept-Language: en
  19. MIME-Version: 1.0
  20. To: Radim Blazek <blazek@itc.it>
  21. Cc: antonin.guttman@informix.com
  22. Subject: Re: R-Tree for GRASS
  23. References: <02071810432200.13881@janacek>
  24. Content-Type: text/plain;
  25. charset=us-ascii
  26. Content-Transfer-Encoding: 7bit
  27. Status: RO
  28. X-Status: O
  29. hello radim,
  30. i'm glad that you're finding my r-tree implementation useful. it should be noted
  31. that i am not the original author. i got my original implementation directly from
  32. toni gutman who i believe co-invented the technique with michael stonebrakier.
  33. that implementation was the same one they'd originally written when testing and
  34. benchmarking the technique. he was not proud of the original code and felt that
  35. while it worked, it would have been better reimplemented from scratch. instead, i
  36. upgraded and polished their code. another user discovered a flaw in the technique
  37. and suggested a solution using bounding spheres which i then implemented. for
  38. example, imagine you have the following three rectangles:
  39. 0,0 to 1,0
  40. 0,2 to 1,3
  41. 1000000,0 to 1000001,0
  42. if you want to partition them into two boxes, the original algorithm based only on
  43. box volumes would have put the first rectangle in one box and the last two in
  44. another. clearly a bad choice for most applications. the bounding sphere metric
  45. would instead place the first two rectangles in one box and the third in another.
  46. much better. it was definitely interesting to extend this to use n-dimensional
  47. spheres, but it does generalize nicely.
  48. your changes to NUMDIMS, and float to double are normal parameters you're expected
  49. to customize. your changes to handle compiler warnings and printf are more
  50. interesting to me. you didn't include your modified files, so i'd appreciate them
  51. which i may use to update the archive. if you can, please make careful note of
  52. your non-cosmetic fixes and improvements. i can't promise to update the archive
  53. but it will at least be useful to have. more likely i'd convert the whole thing
  54. into a nicely objectified java package but there's a good chance i'll never get
  55. around to doing that.
  56. regarding split_l.c vs. split_q.c: these involve a choice you can make between
  57. speed and box optimization. you should use the quadratic version ('q') if it's
  58. fast enough for your needs, and use the less expensive linear method if not. note
  59. that in both cases various branches of the resulting rectangle trees may overlap.
  60. there's another version of the technique called "R+ Trees" which guarantees no
  61. overlaps, but i don't have an implementation of that version. i believe it's even
  62. slower than either r-tree splitting method, so you should probably also take all
  63. of that into account.
  64. i did a quick search and found a citing of toni's work here:
  65. http://www.informatik.uni-trier.de/~ley/db/indices/a-tree/g/Guttman:Antonin.html
  66. for your grass header files, you should list toni's name as author, though i'd
  67. appreciate mention of my updates to his code and technique.
  68. you'll find the abstract of the paper here:
  69. http://www.informatik.uni-trier.de/~ley/db/conf/sigmod/Guttman84.html
  70. and a home page for toni here:
  71. http://es.ucsc.edu/~tonig/
  72. note that you'll also find links to his original paper and implementation there.
  73. i'm cc'ing him in case there's anything he'd like to add or correct; and also so
  74. that if he likes, he can update his implementation with my updated sources. it's
  75. been a very long time since i've talked with him so i hope that address is still
  76. current.
  77. finally, i have a question for you about grass: i've developed a technique based
  78. on r-trees that allows interactive navigation of enormous polygonal 3d data sets.
  79. it's been a solution in search of a problem. i know that some gis application
  80. require such data sets and i'd love to communicate with any that you know of who
  81. might need such a technique. it only works in static environments that are crowded
  82. enough such that regardless of how the user navigates, only a very small fraction
  83. of the entire data set are ever visible at once. it's obviously a very specialized
  84. technique but it scales with the log of the number of polygons and may therefore
  85. be very useful for applications with huge and ever-growing data sets.
  86. -daniel
  87. Radim Blazek wrote:
  88. > Ciao,
  89. >
  90. > I want to use R-Tree http://www.superliminal.com/sources/RTree.zip
  91. > as spatial index for GRASS (GPL GIS) http://grass.itc.it/index.html
  92. >
  93. > I tested just for line intersection function but want to use as general
  94. > index for vectors. Library will be part of GRASS project, but may be
  95. > extracted and compiled independently (Makefile.alone).
  96. >
  97. > I have done just few cosmetic changes so far (described in README.grass):
  98. > - files converted to unix line ends
  99. > - added file 'README.grass'
  100. > - added Makefile
  101. > - few modifications to get rid of compiler warnings, but warnings like:
  102. > index.c:277: warning: `tmp_nptr' might be used uninitialized in this f.
  103. > were left because need deeper revision if may cause problems, insetad of
  104. > blindly init to 0/NULL
  105. > - '//' comments -> '/* */'
  106. > - printf() - > fprintf(stdout,)
  107. > - NUMDIMS set to 3
  108. > - test.c 2D -> 3D
  109. > - type RectReal: float -> double
  110. >
  111. > OK? (I hope so because you write: You're completely free to use them for any
  112. > purpose whatsoever.)
  113. >
  114. > If you don't mind I would like to ask you if you recall
  115. > how split_l.c and split_q.c differ and which should be used?
  116. >
  117. > Can I add headers to your files for GRASS?:
  118. > /****************************************************************************
  119. > * MODULE: R-Tree library
  120. > *
  121. > * AUTHOR(S): Daniel Green (dgreen@superliminal.com)
  122. > *
  123. > * PURPOSE: Multidimensional index
  124. > *
  125. > * COPYRIGHT: (C) 2001 by the GRASS Development Team
  126. > *
  127. > * This program is free software under the GNU General Public
  128. > * License (>=v2). Read the file COPYING that comes with GRASS
  129. > * for details.
  130. > *****************************************************************************/
  131. >
  132. > Thanks
  133. >
  134. > Radim