Re: [postgis-users] [postgis-devel] 3D distance functions
Nicklas, This sounds exciting. I think Oracle has 3D distance support. We don't have Oracle installed at the moment, but perhaps someone with Oracle can do a test compare or we can reinstall later on. We'll try to release another set of windows binaries with your new changes sometime later this week. I think a wiki page would be a great idea. Keep up the good work! Thanks, Regina and Leo http://www.postgis.us -Original Message- From: postgis-devel-boun...@postgis.refractions.net [mailto:postgis-devel-boun...@postgis.refractions.net] On Behalf Of Nicklas Avén Sent: Tuesday, December 28, 2010 5:29 PM To: PostGIS Development Discussion Subject: [postgis-devel] 3D distance functions Hallo all I just committed the rest of the 3D distance functions. There is no regression tests or unit tests yet. There is probably a bunch of bugs, but I commit anyway and hope more people might punch on it. There is a lot of possibilities to consider. The functions are supposed to handle holes in polygons too, so there can be one polygon passing through a hole of another for instance. It should work, but I have actually not tried it yet. One idea I have to make a test suite is to just tilt the geometries from a 2D dataset with st_affine, but it will still be difficult to get answers we know is right. Or is there som other software that we easily can use to check against? Some functions that might be of interest for other things than distance calculations is: define_plane, which defines the plane of a polygon in 3D. How that is done might be a topic for discussion. pt_in_ring_3d, checks is a point on the same plane as the polygon is inside or outside the polygon. project_point_on_plane, gives the point from where the original point is perpendicular to the plane Is it a good idea to make a wiki page, describing how things works, and what situations I have tried to cover up? About make astyle I couldn't run it. I had the message: ./astyle.sh Only 1.23 astyle version is 'allowed' and I have version 1.24 Regards Nicklas ___ postgis-devel mailing list postgis-de...@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-devel ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] Polygon from point query
On 12/28/2010 02:49 PM, Poynter, David wrote:
This is probably an easy one, but being a PostGIS newb I've been spinning my
wheels and haven't the google fu to locate an answer, so here goes...
I have a table of counties from the state (county) and I'm creating a point to
insert in another table and I would like to find the county the point falls in.
I think I should be able to do it in one query rather than looping thru county
by county, but I can't seem to put it together.
SELECT county_nam FROM county WHERE ?
I've been looking at ST_Within() and think the answer lies with it somehow,
thanks for any clues...
I do this in PHP, and am using a query like this:
select fips from county
where the_geom && PointFromText('POINT($longitude $latitude)',4269)
and ST_within(PointFromText('POINT($longitude $latitude)',4269),the_geom)
Since this is a string in PHP, the X coordinate will go where I've
written $longitude and the Y coordinate will go where I've written
$latitude.
The county table in this case is the countyp020 shapefile drawn from
the US National Atlas at nationalatlas.gov. In my case what I want is
the FIPS code of the county.
You can actually try this out online using syntax like this:
http://tin.er.usgs.gov/atlas/point-xml.php?latitude=39&longitude=-77
That service will run your point against a variety of other base polygon
layers, as you can see.
Peter
--
Peter N. Schweitzer (MS 954, U.S. Geological Survey, Reston, VA 20192)
(703) 648-6533 FAX: (703) 648-6252 email: pschweit...@usgs.gov
Re: [postgis-users] Polygon from point query
Hi, You need to have your points already in a table, then you can run a single query to identify the county each lies within. SELECT p.point, c.county_nam FROM county c, points p WHERE ST_Within(p.the_geom, c.the_geom); You can also wrap this in an update statement to have a column in the point table with the id of the county to implement a foreign key to join the two tables on. HTH, Brent Wood --- On Wed, 12/29/10, Poynter, David wrote: From: Poynter, David Subject: [postgis-users] Polygon from point query To: "postgis-users" Date: Wednesday, December 29, 2010, 8:49 AM This is probably an easy one, but being a PostGIS newb I've been spinning my wheels and haven't the google fu to locate an answer, so here goes... I have a table of counties from the state (county) and I'm creating a point to insert in another table and I would like to find the county the point falls in. I think I should be able to do it in one query rather than looping thru county by county, but I can't seem to put it together. SELECT county_nam FROM county WHERE ? I've been looking at ST_Within() and think the answer lies with it somehow, thanks for any clues... -Inline Attachment Follows- ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] Polygon from point query
You are looking for st_intersects() http://postgis.refractions.net/documentation/manual-1.5/ST_Intersects.html David. On Tue, Dec 28, 2010 at 1:49 PM, Poynter, David wrote: > This is probably an easy one, but being a PostGIS newb I've been spinning my > wheels and haven't the google fu to locate an answer, so here goes... > > > > I have a table of counties from the state (county) and I'm creating a point > to insert in another table and I would like to find the county the point > falls in. > > I think I should be able to do it in one query rather than looping thru > county by county, but I can't seem to put it together. > > > > SELECT county_nam FROM county WHERE ? > > > > I've been looking at ST_Within() and think the answer lies with it somehow, > thanks for any clues... > > ___ > postgis-users mailing list > postgis-users@postgis.refractions.net > http://postgis.refractions.net/mailman/listinfo/postgis-users > > ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
[postgis-users] Polygon from point query
This is probably an easy one, but being a PostGIS newb I've been spinning my wheels and haven't the google fu to locate an answer, so here goes... I have a table of counties from the state (county) and I'm creating a point to insert in another table and I would like to find the county the point falls in. I think I should be able to do it in one query rather than looping thru county by county, but I can't seem to put it together. SELECT county_nam FROM county WHERE ? I've been looking at ST_Within() and think the answer lies with it somehow, thanks for any clues... ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] Traverse set distance along a multiline?
Hi Aren, for start & end points you can use ST_StartPoint & ST_EndPoint, should be faster than 0 & 100% values. It may also be useful to optimise your working data, by pre ordering the points so that the startpoint is always the southern or western one, so your algorithm does not need to check this for every linestring, eg: update table set geom_nad = ST_Reverse(geom_nad) where ST_StartPoint(geom_nad) |>> ST_EndPoint(geom_nad); see: http://www.postgis.org/documentation/manual-1.5/reference.html#Operators --- On Wed, 12/29/10, Aren Cambre wrote: From: Aren Cambre Subject: Re: [postgis-users] Traverse set distance along a multiline? To: postgis-users@postgis.refractions.net Date: Wednesday, December 29, 2010, 5:00 AM Just want to again say thanks for all the help on this. After projecting from 4269 to 3081, I reanalyzed everything and checked my points sample again. All my points at major intersections and state borders were <= 1 mile off! That's good enough for me. Now my next two problems (which I need to research) are:Forcing my algorithm to start mile 0 from a route's the southern or western extreme. I am guessing I would get the points at 0% and 100% of a route and the compare them. Whichever "wins" then becomes the starting point for my traversal. At least for most mainline IH and US routes, the algorithm to determine the "winner" may takes the route number as input since even = W-E and odd = N-S. Connecting some routes that are inconsistent or noncontiguous. Examples I've found in the Interstate system:Where I-35W and I-35E split south of Dallas/Ft. Worth, I-35W starts over at mile marker 0, but I-35E maintains mileposts as if it is the contiguous I-35 route. So I need to connect I-35 south of Dallas, I-35E, and I-35 north Dallas as one route. I think the PostGIS functions exist to combine these three routes into one. I-10 for some reason doesn't follow I-35 near downtown San Antonio, so I have two I-10s separated by that short I-35 multiplex gap. Mile markers on a contiguous route would count up to well over 800 by the Sabine River (eastern Texas border). Aren On Sun, Dec 26, 2010 at 6:35 PM, Aren Cambre wrote: I am trying to determine mile markers along Texas highways. My starting point is the ShapeFile TxDOT Roadways 2010 at http://www.tnris.state.tx.us/datadownload/download.jsp. I've used shp2pgsql to get it into a PostGIS 1.52-enabled Postgres 9.01 database. I naively thought I could just figure out the number of miles per unit of latitude and then traverse each roadway, one mile at a time, using ST_Line_Interpolate_Point. However, predictably, the more "longitudinal" a route, the more error it shows when I compare my calculated mile markers to what Google Maps shows. Again, this is because I was using a consistent ratio of degrees to miles, so any route E-W component introduces errors. So here's the question--does PostGIS allow any way to traverse a route a set distance at a time? Specifically, is there a way I can traverse a route a mile at a time and then record the points at the end of each mile? I reviewed the functions available at http://postgis.refractions.net/documentation/manual-1.5/reference.html and am not seeing anything clear. In case it matters, the SHP's PRJ file says NAD83. Aren Cambre -Inline Attachment Follows- ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] Traverse set distance along a multiline becoming multiple storage columns?
Hi Ben, I'm interested in what an authoritative answer is to this :-) I know that several years (& Postgis/Postgres versions) ago running a query on this setup, then dropping the original column & vacuuming & re-running the query didn't make a significant difference, coz I tried it, but this was with only around 66,000 records. I should try it with a couple of hundred million with v9/1.52 & see what happens. It obviously does impact on filesystem volume & dumps/backups, which could be an issue for some. Maybe something to play with while at sea in January. if I have the time. Cheers, Brent --- On Tue, 12/28/10, Ben Madin wrote: From: Ben Madin Subject: Re: [postgis-users] Traverse set distance along a multiline becoming multiple storage columns? To: "PostGIS Users Discussion" Cc: "Brent Wood" Date: Tuesday, December 28, 2010, 11:29 PM I've done it this way, but now may be the time for me to check... I have often wondered if because the Geometry is stored in a TOAST table, this shouldn't impact on speed should it? cheers Ben On 28/12/2010, at 5:57 PM, pcr...@pcreso.com wrote: Hi Aren, In this sort of case I usually prefer to keep my source data as a reference, as well as an indexed reprojected (working) version of the geometry. Instead of doing it as you have done, and create a new table, I add a new geometry column of the appropriate type & SRID to the original table, then populate it using an update (& don't forget to index it): eg: select ST_AddGeometryColumn( '','txdot_roadways','geom_nad',3081,'LINESTRING',2);" update txdot_roadways set geom_nad=ST_Transform(the_geom, 3081); (& if your original geometry is a MULTILINESTRING, then use that type instead) This keeps the two geometries together in the same table, something that is non-trivial in a traditional GIS, but just another column in spatially enabled database. If you really don't need to keep the original column, you can always drop it from the table after creating the 3081 version. Having a second table also works, but I figured I'd mention this alternative. Cheers, Brent Wood --- On Tue, 12/28/10, Aren Cambre wrote: From: Aren Cambre Subject: Re: [postgis-users] Traverse set distance along a multiline? To: "PostGIS Users Discussion" Date: Tuesday, December 28, 2010, 6:50 PM Thank you. Now my shp2pgsql conversion results in a PostGIS table with an SRID. I then ran this query to reproject the data into a new table:INSERT INTO txdot_roadways_3081_transform SELECT [all other fields go here], ST_Transform(the_geom, 3081) as the_geomFROM txdot_roadways; Loading into qgis, the map now looks like a correct projection for taking planar (?) measurements. Previously the state looked as if it was stretched horizontally, but I guess that's to be expected if longitudinal lines don't bend. Thanks again to both of you for helping with this. It never occurred to me how easy it can be to reproject GIS data. Aren On Mon, Dec 27, 2010 at 6:15 PM, Paul Ramsey wrote: Right, use 4269, that's a good NAD83-geographic-coordinates number. Import with shp2pgsql -s 4269 and go from there. P On Mon, Dec 27, 2010 at 3:54 PM, Aren Cambre wrote: > Brent and Paul, > Thank you for your help! > So here's my (new) dilemma--my PostGIS table doesn't appear to have a > projection specified, and I am not clear how to get to one. > I don't think it has a projection because this table's corresponding entry > in the geometry_columns table has -1 for the srid column. > This ShapeFile's PRJ file has this: > GEOGCS["GCS_North_American_1983",DATUM["D_North_American_1983",SPHEROID["GRS_1980",6378137.0,298.257222101]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]] > I'm not seeing a clear match between this and any projection. > Some Google searching suggests this may be 4326, but I'm not sure about > this. And if I modify geometry_columns and import the PostGIS table into > QGis, I get this QGis error: > 1 cursor states lost. > SQL: CLOSE qgisf0 > Result: 7 (ERROR: current transaction is aborted, commands ignored until > end of transaction block > ) > If I revert that field back to -1, the error goes away on next import. > When I imported using shp2pgsql, I didn't use the -s switch. I presumed it > would catch the projection automatically. > I'm at a loss to know what to do next. I guess I need to figure out what the > true SRID of this data is before I can do any re-projections? > Aren > > On Mon, Dec 27, 2010 at 12:22 AM, Paul Ramsey wrote: >> >> You need to do your analysis in a projected coordinate system, not >> geographics. >> >> CREATE TABLE my_new_texas_roads AS >> SELECT ST_Transform(the_geom, 3081) as the_geom, other_attributes >> FROM texas_roads; >> >> EPSG:3081 should be a good coordinate system for working with your Texas >> data. >> >> http://spatialreference.org/ref/epsg/3081/ >> >> Not that the units are meters, so perform the appropriate linear >>
Re: [postgis-users] Traverse set distance along a multiline?
Just want to again say thanks for all the help on this. After projecting from 4269 to 3081, I reanalyzed everything and checked my points sample again. All my points at major intersections and state borders were <= 1 mile off! That's good enough for me. Now my next two problems (which I need to research) are: 1. Forcing my algorithm to start mile 0 from a route's the southern or western extreme. I am guessing I would get the points at 0% and 100% of a route and the compare them. Whichever "wins" then becomes the starting point for my traversal. At least for most mainline IH and US routes, the algorithm to determine the "winner" may takes the route number as input since even = W-E and odd = N-S. 2. Connecting some routes that are inconsistent or noncontiguous. Examples I've found in the Interstate system: - Where I-35W and I-35E split south of Dallas/Ft. Worth, I-35W starts over at mile marker 0, but I-35E maintains mileposts as if it is the contiguous I-35 route. So I need to connect I-35 south of Dallas, I-35E, and I-35 north Dallas as one route. I think the PostGIS functions exist to combine these three routes into one. - I-10 for some reason doesn't follow I-35 near downtown San Antonio, so I have two I-10s separated by that short I-35 multiplex gap. Mile markers on a contiguous route would count up to well over 800 by the Sabine River (eastern Texas border). Aren On Sun, Dec 26, 2010 at 6:35 PM, Aren Cambre wrote: > I am trying to determine mile markers along Texas highways. My starting > point is the ShapeFile TxDOT Roadways 2010 at > http://www.tnris.state.tx.us/datadownload/download.jsp. I've used > shp2pgsql to get it into a PostGIS 1.52-enabled Postgres 9.01 database. > > I naively thought I could just figure out the number of miles per unit of > latitude and then traverse each roadway, one mile at a time, using * > ST_Line_Interpolate_Point*. However, predictably, the more "longitudinal" > a route, the more error it shows when I compare my calculated mile markers > to what Google Maps shows. > > Again, this is because I was using a consistent ratio of degrees to miles, > so any route E-W component introduces errors. > > So here's the question--does PostGIS allow any way to traverse a route a > set distance at a time? Specifically, is there a way I can traverse a route > a mile at a time and then record the points at the end of each mile? > > I reviewed the functions available at > http://postgis.refractions.net/documentation/manual-1.5/reference.html and > am not seeing anything clear. > > In case it matters, the SHP's PRJ file says NAD83. > > Aren Cambre > ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] Traverse set distance along a multiline?
Thank you. Another method I've used is a hybrid model where I create a separate table but have a foreign key going back to the original table, then I make a view to combine both tables. I preserve the original table and have my separate table that I can throw away if I need. Aren On Tue, Dec 28, 2010 at 12:57 AM, wrote: > Hi Aren, > > In this sort of case I usually prefer to keep my source data as a > reference, as well as an indexed reprojected (working) version of the > geometry. Instead of doing it as you have done, and create a new table, I > add a new geometry column of the appropriate type & SRID to the original > table, then populate it using an update (& don't forget to index it): > > eg: > > select ST_AddGeometryColumn( '',' > txdot_roadways','geom_nad',3081,'LINESTRING',2);" > update txdot_roadways set geom_nad=ST_Transform(the_geom, 3081); > > (& if your original geometry is a MULTILINESTRING, then use that type > instead) > > This keeps the two geometries together in the same table, something that is > non-trivial in a traditional GIS, but just another column in spatially > enabled database. If you really don't need to keep the original column, you > can always drop it from the table after creating the 3081 version. > > Having a second table also works, but I figured I'd mention this > alternative. > > Cheers, > > Brent Wood > > --- On *Tue, 12/28/10, Aren Cambre * wrote: > > > From: Aren Cambre > Subject: Re: [postgis-users] Traverse set distance along a multiline? > To: "PostGIS Users Discussion" > Date: Tuesday, December 28, 2010, 6:50 PM > > > Thank you. Now my shp2pgsql conversion results in a PostGIS table with an > SRID. I then ran this query to reproject the data into a new table: > *INSERT INTO txdot_roadways_3081_transform* > *SELECT [all other fields go here], ST_Transform(the_geom, 3081) as > the_geom* > *FROM txdot_roadways;* > > Loading into qgis, the map now looks like a correct projection for taking > planar (?) measurements. Previously the state looked as if it > was stretched horizontally, but I guess that's to be expected if > longitudinal lines don't bend. > > Thanks again to both of you for helping with this. It never occurred to me > how easy it can be to reproject GIS data. > > Aren > > On Mon, Dec 27, 2010 at 6:15 PM, Paul Ramsey > http://mc/compose?to=pram...@opengeo.org> > > wrote: > > Right, use 4269, that's a good NAD83-geographic-coordinates number. > Import with shp2pgsql -s 4269 and go from there. > > P > > On Mon, Dec 27, 2010 at 3:54 PM, Aren Cambre > http://mc/compose?to=a...@arencambre.com>> > wrote: > > Brent and Paul, > > Thank you for your help! > > So here's my (new) dilemma--my PostGIS table doesn't appear to have a > > projection specified, and I am not clear how to get to one. > > I don't think it has a projection because this table's corresponding > entry > > in the geometry_columns table has -1 for the srid column. > > This ShapeFile's PRJ file has this: > > > GEOGCS["GCS_North_American_1983",DATUM["D_North_American_1983",SPHEROID["GRS_1980",6378137.0,298.257222101]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]] > > I'm not seeing a clear match between this and any projection. > > Some Google searching suggests this may be 4326, but I'm not sure about > > this. And if I modify geometry_columns and import the PostGIS table into > > QGis, I get this QGis error: > > 1 cursor states lost. > > SQL: CLOSE qgisf0 > > Result: 7 (ERROR: current transaction is aborted, commands ignored until > > end of transaction block > > ) > > If I revert that field back to -1, the error goes away on next import. > > When I imported using shp2pgsql, I didn't use the -s switch. I presumed > it > > would catch the projection automatically. > > I'm at a loss to know what to do next. I guess I need to figure out what > the > > true SRID of this data is before I can do any re-projections? > > Aren > > > > On Mon, Dec 27, 2010 at 12:22 AM, Paul Ramsey > > http://mc/compose?to=pram...@opengeo.org>> > wrote: > >> > >> You need to do your analysis in a projected coordinate system, not > >> geographics. > >> > >> CREATE TABLE my_new_texas_roads AS > >> SELECT ST_Transform(the_geom, 3081) as the_geom, other_attributes > >> FROM texas_roads; > >> > >> EPSG:3081 should be a good coordinate system for working with your Texas > >> data. > >> > >> http://spatialreference.org/ref/epsg/3081/ > >> > >> Not that the units are meters, so perform the appropriate linear > >> transformations when looking for mile markers. > >> > >> Paul > >> > >> On Sun, Dec 26, 2010 at 4:35 PM, Aren Cambre > >> http://mc/compose?to=a...@arencambre.com>> > wrote: > >> > I am trying to determine mile markers along Texas highways. My > starting > >> > point is the ShapeFile TxDOT Roadways 2010 > >> > at http://www.tnris.state.tx.us/datadownload/download.jsp. I've used > >> > shp2pgsql to get it into a PostGIS 1.52-enabled Postgres 9.01 > database. > >> > I naively thought I could just figu
Re: [postgis-users] Traverse set distance along a multiline becoming multiple storage columns?
I've done it this way, but now may be the time for me to check... I have often wondered if because the Geometry is stored in a TOAST table, this shouldn't impact on speed should it? cheers Ben On 28/12/2010, at 5:57 PM, pcr...@pcreso.com wrote: > Hi Aren, > > In this sort of case I usually prefer to keep my source data as a reference, > as well as an indexed reprojected (working) version of the geometry. Instead > of doing it as you have done, and create a new table, I add a new geometry > column of the appropriate type & SRID to the original table, then populate it > using an update (& don't forget to index it): > > eg: > > select ST_AddGeometryColumn( > '','txdot_roadways','geom_nad',3081,'LINESTRING',2);" > update txdot_roadways set geom_nad=ST_Transform(the_geom, 3081); > > (& if your original geometry is a MULTILINESTRING, then use that type instead) > > This keeps the two geometries together in the same table, something that is > non-trivial in a traditional GIS, but just another column in spatially > enabled database. If you really don't need to keep the original column, you > can always drop it from the table after creating the 3081 version. > > Having a second table also works, but I figured I'd mention this alternative. > > Cheers, > > Brent Wood > > --- On Tue, 12/28/10, Aren Cambre wrote: > > From: Aren Cambre > Subject: Re: [postgis-users] Traverse set distance along a multiline? > To: "PostGIS Users Discussion" > Date: Tuesday, December 28, 2010, 6:50 PM > > Thank you. Now my shp2pgsql conversion results in a PostGIS table with an > SRID. I then ran this query to reproject the data into a new table: > INSERT INTO txdot_roadways_3081_transform > SELECT [all other fields go here], ST_Transform(the_geom, 3081) as the_geom > FROM txdot_roadways; > > Loading into qgis, the map now looks like a correct projection for taking > planar (?) measurements. Previously the state looked as if it was stretched > horizontally, but I guess that's to be expected if longitudinal lines don't > bend. > > Thanks again to both of you for helping with this. It never occurred to me > how easy it can be to reproject GIS data. > > Aren > > On Mon, Dec 27, 2010 at 6:15 PM, Paul Ramsey wrote: > Right, use 4269, that's a good NAD83-geographic-coordinates number. > Import with shp2pgsql -s 4269 and go from there. > > P > > On Mon, Dec 27, 2010 at 3:54 PM, Aren Cambre wrote: > > Brent and Paul, > > Thank you for your help! > > So here's my (new) dilemma--my PostGIS table doesn't appear to have a > > projection specified, and I am not clear how to get to one. > > I don't think it has a projection because this table's corresponding entry > > in the geometry_columns table has -1 for the srid column. > > This ShapeFile's PRJ file has this: > > GEOGCS["GCS_North_American_1983",DATUM["D_North_American_1983",SPHEROID["GRS_1980",6378137.0,298.257222101]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]] > > I'm not seeing a clear match between this and any projection. > > Some Google searching suggests this may be 4326, but I'm not sure about > > this. And if I modify geometry_columns and import the PostGIS table into > > QGis, I get this QGis error: > > 1 cursor states lost. > > SQL: CLOSE qgisf0 > > Result: 7 (ERROR: current transaction is aborted, commands ignored until > > end of transaction block > > ) > > If I revert that field back to -1, the error goes away on next import. > > When I imported using shp2pgsql, I didn't use the -s switch. I presumed it > > would catch the projection automatically. > > I'm at a loss to know what to do next. I guess I need to figure out what the > > true SRID of this data is before I can do any re-projections? > > Aren > > > > On Mon, Dec 27, 2010 at 12:22 AM, Paul Ramsey wrote: > >> > >> You need to do your analysis in a projected coordinate system, not > >> geographics. > >> > >> CREATE TABLE my_new_texas_roads AS > >> SELECT ST_Transform(the_geom, 3081) as the_geom, other_attributes > >> FROM texas_roads; > >> > >> EPSG:3081 should be a good coordinate system for working with your Texas > >> data. > >> > >> http://spatialreference.org/ref/epsg/3081/ > >> > >> Not that the units are meters, so perform the appropriate linear > >> transformations when looking for mile markers. > >> > >> Paul > >> > >> On Sun, Dec 26, 2010 at 4:35 PM, Aren Cambre wrote: > >> > I am trying to determine mile markers along Texas highways. My starting > >> > point is the ShapeFile TxDOT Roadways 2010 > >> > at http://www.tnris.state.tx.us/datadownload/download.jsp. I've used > >> > shp2pgsql to get it into a PostGIS 1.52-enabled Postgres 9.01 database. > >> > I naively thought I could just figure out the number of miles per unit > >> > of > >> > latitude and then traverse each roadway, one mile at a time, > >> > using ST_Line_Interpolate_Point. However, predictably, the more > >> > "longitudinal" a route, the more error it shows when I compare my > >> > calcu
