| 06:16:00 | sigq: | geosfeed: Ticket #92 ( defect updated ): MarkupSTL.cpp - always true comparison <http://trac.osgeo.org/geos/ticket/92#comment:7> |
| 06:28:17 | sigq: | geosfeed: Ticket #219 ( defect updated ): This geometry causes buffer( ?, 0 ) to crash the PostGresql server <http://trac.osgeo.org/geos/ticket/219#comment:4> |
| 06:38:14 | CIA-34: | strk * r2471 /trunk/source/ ( 2 files in 2 dirs ): Add port info. We're 4 revision old ( catching up next ) |
| 06:51:07 | CIA-34: | strk * r2472 /trunk/source/ ( 2 files in 2 dirs ): Port to 1.9, fixing an out of boundary access in findEdgeEnd |
| 07:27:33 | CIA-34: | strk * r2473 /trunk/source/ ( 2 files in 2 dirs ): Port MonotoneChainBuilder up to JTS-1.10. Tweak some signatures to use stricter signedness. |
| 07:28:55 | : | * JGH blinks |
| 07:43:07 | CIA-34: | strk * r2474 /trunk/source/ ( 2 files in 2 dirs ): Port MonotoneChain up to JTS-1.10, plus minor dox improvement ( memory-oriented ) |
| 08:32:16 | CIA-34: | strk * r2475 /trunk/source/ ( 2 files in 2 dirs ): Const-correctness for bintree Interval |
| 09:06:03 | CIA-34: | strk * r2477 /trunk/source/ ( 6 files in 5 dirs ): MonotoneChainSelectAction port review, heap allocation reduced, const-corrected. |
| 09:10:29 | CIA-34: | strk * r2478 /trunk/source/ ( 2 files in 2 dirs ): Port info ( to be worked on for heap allocations reduction ) |
| 09:39:00 | CIA-34: | strk * r2479 /trunk/source/ ( 9 files in 5 dirs ): Cleanup MonotoneChainOverlapAction, reduce heap allocations. Cascade changes. |
| 09:40:13 | strk: | Monotone Chains at JTS-1.10 too now |
| 09:48:02 | CIA-34: | strk * r2480 /trunk/source/operation/buffer/BufferBuilder.cpp: minor indentation thing |
| 09:50:39 | CIA-34: | strk * r2481 /trunk/source/ ( 2 files in 2 dirs ): findCollapsesFromExistingVertices: don't choke on sets of < 2 points. Fixes bug #219. |
| 09:51:52 | sigq: | geosfeed: Ticket #219 ( defect closed ): This geometry causes buffer( ?, 0 ) to crash the PostGresql server <http://trac.osgeo.org/geos/ticket/219#comment:5> |
| 09:56:28 | sigq: | geosfeed: Ticket #219 ( defect updated ): This geometry causes buffer( ?, 0 ) to crash the PostGresql server <http://trac.osgeo.org/geos/ticket/219#comment:6> |
| 09:58:08 | CIA-34: | robe * r4071 /branches/1.3/NEWS: Update News in prep for official 1.3.6 announcement ( add missing items -- put in trac # where known ). Would have been better in 1.3.6 tag oh well. |
| 10:00:48 | CIA-34: | robe * r4072 /trunk/NEWS: update with 1.3.6 items |
| 10:01:58 | sigq: | geosfeed: Ticket #219 ( defect updated ): This geometry causes buffer( ?, 0 ) to crash the PostGresql server <http://trac.osgeo.org/geos/ticket/219#comment:7> |
| 10:07:05 | CIA-34: | robe * r4073 /trunk/NEWS: typo |
| 10:07:34 | CIA-34: | robe * r4074 /branches/1.3/NEWS: typo |
| 10:24:46 | sjzzalx: | I can't seem to locate how I can convert from WGS84 latitude/longitude format on the last parameter of ST_DWithin to miles. Anyone here know? |
| 10:25:45 | pimpaa: | you probably need to transform you data to another EPSG to use miles in the calculation |
| 10:26:12 | pimpaa: | for instance UTM |
| 10:26:20 | pimpaa: | or any suitable utm for your area |
| 10:26:58 | pimpaa: | st_transform if im not mistaken. it can be done in runtime, no need to duplicate your dataset, but it will take some time if the dataset is large enough |
| 10:27:25 | sjzzalx: | Or, phrased less dumbly: I need to do ST_DWitihn( a, b, 40 ), which I want to return all items within 40 miles, but my geoms are stored as WGS84 and ST_DWithin seems to be using longitude or something right now. |
| 10:27:46 | sjzzalx: | pimpaa: OK. I had a hard time finding the SRID to convert to for miles. Any suggestions? |
| 10:27:59 | sjzzalx: | and thank you. : ) |
| 10:28:13 | pimpaa: | where is your data located? |
| 10:28:17 | pimpaa: | theres is a cool website just a sec |
| 10:29:06 | pimpaa: | im not gonna finda it now, im on another machine |
| 10:29:40 | pimpaa: | http://www.remotesensing.org/geotiff/proj_list/ |
| 10:29:41 | sigq: | Title: Projections List ( at www.remotesensing.org ) |
| 10:29:50 | pimpaa: | this is the projections suported by postgis |
| 10:29:58 | pimpaa: | ; ) sigq |
| 10:32:49 | sjzzalx: | pimpaa: thanks, but I really don't know what any of that means :( |
| 10:33:14 | pimpaa: | you dont have a background knowledge of cartography? |
| 10:33:38 | pimpaa: | i suggest you read a bit about projections and reference systems |
| 10:33:45 | sjzzalx: | pimpaa: No, I don't. Sorry. :( Is there a good primer I could read? |
| 10:33:53 | pimpaa: | let me think |
| 10:34:33 | pimpaa: | there is a good book by esri |
| 10:34:38 | pimpaa: | understanding map projections |
| 10:34:52 | pimpaa: | that will guide you to basic understading of projections and RS |
| 10:34:58 | pimpaa: | reference systems |
| 10:35:04 | pimpaa: | its a quite cheap book too |
| 10:35:07 | pimpaa: | http://store.esri.com/esri/showdetl.cfm?SID=2&Product_ID=1133&Category_ID=28 |
| 10:35:08 | sigq: | Title: ESRI Store: Browsing Understanding Map Projections ( at store.esri.com ) |
| 10:35:27 | pimpaa: | im sorry i dont know any free material to show you here |
| 10:35:35 | pimpaa: | http://www.kartografie.nl/geometrics/Map%20projections/Understanding%20Map%20Projections.pdf |
| 10:35:39 | pimpaa: | well just found the book online |
| 10:35:41 | pimpaa: | for free |
| 10:35:45 | pimpaa: | check that pdf out |
| 10:36:19 | sjzzalx: | pimpaa: Cool, thanks. : ) |
| 10:36:38 | pimpaa: | probably there are many college websites with classes online availuable |
| 10:36:41 | pimpaa: | look for that too |
| 10:40:53 | sjzzalx: | ok, thanks. So, unfortunately, there's not a just a simple SRID I can convert to, I need to learn all of this and craft specify WKT or something like that? |
| 10:41:24 | pimpaa: | nope |
| 10:41:49 | pimpaa: | the most used projections, datums and reference systems are availuable in postgis |
| 10:41:56 | pimpaa: | what im trying to point to you |
| 10:42:11 | pimpaa: | is that the choice of SRID depends largely on what you WANT to do with your data |
| 10:42:38 | pimpaa: | there are projections that are suitable for area/distance calculations, others that preserve shape, others preserve angles |
| 10:42:52 | pimpaa: | and depends of where your data is located |
| 10:43:38 | pimpaa: | if your data is located worldwide, you CANNOT use a utm projection, because in UTM, the whole world is sliced, and to achieve maximum precision your data must be inside that slice |
| 10:43:51 | pimpaa: | there are datums and projections suitable for US |
| 10:43:59 | pimpaa: | others that are suitable for each american state |
| 10:44:13 | pimpaa: | others that can be applied to data in Africa, Brazil, South America, etc |
| 10:50:24 | pimpaa: | understood sjzzalx ? |
| 11:01:46 | sigq: | geosfeed: Ticket #92 ( defect updated ): MarkupSTL.cpp - always true comparison <http://trac.osgeo.org/geos/ticket/92#comment:8> |
| 12:09:00 | CIA-34: | mloskot * r2482 /trunk/source/headers/geos/operation/overlay/snap/: Updated svn:ignore property. |
| 12:14:19 | strk: | pramsey: have you looked at that buffer( 0 ) geoms ? |
| 12:14:30 | pramsey: | no |
| 12:14:45 | strk: | not sure a user willing to cleanup a geom really wants that output |
| 12:15:11 | strk: | wget http://foo.keybit.net/~strk/tmp/bug219.xml |
| 12:15:22 | strk: | XMLTester -v -v --sqloutput bug219.xml | psql |
| 12:15:34 | strk: | qgis && load bug219_xml.a and bug219_xml.obtained |
| 12:16:04 | strk: | oh, it's --sql-output |
| 12:18:21 | CIA-34: | strk * r2483 /trunk/tests/xmltester/markup/MarkupSTL.cpp: Fix compilation warnings thrown by GCC 4.3.x. Patch by Mateus, closes bug #92. |
| 12:19:27 | strk: | actually, lemme give you the sql directly |
| 12:19:27 | sigq: | geosfeed: Ticket #92 ( defect closed ): MarkupSTL.cpp - always true comparison <http://trac.osgeo.org/geos/ticket/92#comment:9> |
| 12:22:57 | strk: | http://foo.keybit.net/~strk/tmp/bug219.sql |
| 12:24:06 | sigq: | geosfeed: bug219.xml attached to ticket #219 <http://trac.osgeo.org/geos/attachment/ticket/219/bug219.xml> |
| 12:25:13 | sigq: | geosfeed: Ticket #219 ( defect updated ): This geometry causes buffer( ?, 0 ) to crash the PostGresql server <http://trac.osgeo.org/geos/ticket/219#comment:8> |
| 12:43:40 | CIA-34: | strk * r2484 /trunk/capi/ ( geos_c.h.in geos_ts_c.cpp ): Fix bug #135, give an hint about GEOSGeom_getDimensions being related to GEOSCoordSeq_getDimensions, fix signed vs. unsigned compiler warning. |
| 12:46:12 | sigq: | geosfeed: Ticket #135 ( defect updated ): *_getDimensions functions do not return correct dimensions <http://trac.osgeo.org/geos/ticket/135#comment:6> |
| 12:51:18 | sjzzalx: | Hello, sorry, network trouble. : ) pimaa: Yes, I understand. :\. I just have a very basic use for PostGIS right now, which is to find the number of things within an area, but all of the SRID etc. makes it take a longer time than I know. I would like to try to to use a UTM for the whole United States, but I can't seem to find the right SRID to convert to for that, or whether that will give me miles or not :( |
| 13:05:05 | DavidAndCarr: | trying to install postGIS, just installed postgreSQL in /usr/local/pgsql/ and when i try and run the configure on postGIS it is telling me that postgreSQL is required.. is there something I'm missing? |
| 13:38:19 | DavidAndCarr: | hmm getting closer |
| 13:42:19 | robe2: | sjzzalx -- try national atals SRID 2163 -- it covers the whole US and I think within about 10 meters of accuracy ( well depends where you are and what you are doing ), for most of my use cases its accurate enough |
| 13:45:09 | sjzzalx: | robe2: Thanks very much. I'm not sure if that's what I need anymore, though ... ST_Distance seems to work without trouble, but ST_DWithin doesn't seem to be returning accurate data, or it's taking things in incorrectly. |
| 13:46:28 | sjzzalx: | Because, ST_Distance gives me what I expect, a distance in meters; but ST_DWithin reports that things are within 17 units of each other, when they're really thousands of miles apart. This is much more than 17 meters. The docs on DWithin appear to indicate that the float should automatically use the units of the first two geom's SRID. |
| 13:46:58 | sjzzalx: | Which, in the case of WGS84, should be meters. Correct? So, I don't understand why I'm not getting good results with this. I'm trying to figure out USING SRID right now. |
| 13:47:15 | robe2: | Yes ST_DWithin uses same units as ST_Distance |
| 13:47:37 | robe2: | WGS84 long lat would return degrees |
| 13:48:34 | sjzzalx: | ST_Distance returns meters to me. Is it possible that it's expecting degrees difference in ST_DWithin, and using that? I'd believe that these things that are 1000 miles apart are 17 degrees apart, but I don't really know much about long/lat or other things |
| 13:48:35 | robe2: | What does your query look like? What does ST_AsText of one of your geometries look like |
| 13:50:26 | sjzzalx: | ST_AsText returns something like "POINT( -121.330605 39.918093 )" |
| 13:52:32 | sjzzalx: | robe2: http://pastebin.com/m2faba6bf is my query; 17.3 is the point where DWithin switches from f to t |
| 13:52:33 | sigq: | Title: pastebin - collaborative debugging tool ( at pastebin.com ) |
| 15:16:36 | CIA-34: | kneufeld * r4075 /trunk/ ( 34 files in 3 dirs ): Added code that will automatically generate the spatial images used in the documentation from WKT input. |
| 15:28:52 | CIA-34: | kneufeld * r4076 /trunk/doc/html/image_src/ ( 20 files ): |
| 15:28:52 | CIA-34: | removed horrible dos carriage returns |
| 15:28:52 | CIA-34: | - convert to unix |
| 18:43:03 | elliotf: | I'm attempting to upgrade postgis running on postgres 8.0 to postgis on postgres 8.3. I'm using http://postgis.refractions.net/documentation/manual-1.3/ch02.html as reference, but the hard upgrade script only spits out four lines ( the last being "Scanning lwpostgis.sql" ) |
| 18:43:04 | sigq: | Title: Chapter 2. Installation ( at postgis.refractions.net ) |
| 18:43:07 | elliotf: | this is on ubuntu 8.04 |
| 18:43:31 | elliotf: | I'll do an strace to see if it's dying on something obvious ( without err ) |
| 18:44:22 | TheSteve0: | I don't know the real answer but could you pgdump the tables - upgrade - and then pgload the data back in |
| 18:44:23 | elliotf: | hrm, it might have been a permissions issue.. |
| 18:44:45 | elliotf: | how do you upgrade without loading the data? |
| 18:45:18 | elliotf: | ah, it's a filter... |
| 18:45:31 | elliotf: | spitting out a new version of the dump file.. |
| 18:45:32 | elliotf: | k. |
| 18:45:49 | elliotf: | well, sorry for the noise, it appears to be chugging along |
| 18:49:22 | TheSteve0: | np, the more the merrier |
| 18:51:14 | elliotf: | I'll chime in again if/when it fails/succeeds |
| 19:13:36 | DavidAndCarr: | trying to install postGIS, just installed postgreSQL in /usr/local/pgsql/ and when i try and run the configure on postGIS it is telling me that postgreSQL is required.. is there something I'm missing? |
| 19:16:36 | TheSteve0: | distro? |
| 19:16:40 | DavidAndCarr: | osx |
| 19:16:46 | TheSteve0: | ahhhh |
| 19:16:48 | TheSteve0: | hhhmmm |
| 19:17:05 | DavidAndCarr: | i've also tried: ./configure --with-pgsql=/usr/local/pgsql/bin/pg_config |
| 19:17:18 | DavidAndCarr: | but when i do my check at the end it says there was an error |
| 19:18:22 | TheSteve0: | hmmm I don't think I will be much help |
| 19:18:27 | TheSteve0: | does it tell you the error? |
| 19:18:49 | DavidAndCarr: | WARNING: Makefile.config.in seems to ignore the --datarootdir setting |