<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style>
</head>
<body class='hmmessage'>
<br><br>Thanks Michael, the lack of a geometry_columns entry for my table was indeed the problem.<br>Regards<br>Victor<br>> <br>> Message: 9<br>> Date: Sun, 08 May 2011 12:42:26 +0200<br>> From: Micha?l Michaud <michael.michaud@free.fr><br>> Subject: Re: [postgis-users] Problem refreshing table list<br>> To: PostGIS Users Discussion <postgis-users@postgis.refractions.net><br>> Message-ID: <4DC67392.3080405@free.fr><br>> Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"<br>> <br>> Hi George,<br>> <br>> As far as OpenJUMP is concerned, the problem could be that the <br>> geometry_columns table is not updated, depending on how you created your <br>> tables under PostgreSQL/PostGIS.<br>> Using addGeometryColumn() function when you create your tables should <br>> update the geometry_columns table automagically.<br>> <br>> In OpenJUMP, while using Open > Database menu, only tables available in <br>> geometry_columns are displayed<br>> However, using Layer > Execute SQL query let you query your database <br>> even if geometry_columns table is empty<br>> <br>> Hope that helps<br>> <br>> Micha?l<br>> <br>> <br>> Le 08/05/2011 12:04, George Washington a ?crit :<br>> > Hi, I have a strange problem no doubt the result of my lack of <br>> > knowledge. Using Postgresql 9.3/PostGIS 1.5.2 under Windows 7 32-bit <br>> > when I look at a database list of tables using PGAdminIII or <br>> > PhpPgAdmin all is well. But when I use OpenJump or Udig all I see is <br>> > an old list of tables. Changes which are reflected in PGAdminIII or <br>> > PhpPgAdmin are not seen by the other two client programs. Restarting <br>> > the server makes no difference.<br>> > What am I missing?<br>> > Many thanks for your help<br>> > George<br>> > ------------------------------------------------------------------------<br>> ><br>> ><br>> > _______________________________________________<br>> > postgis-users mailing list<br>> > postgis-users@postgis.refractions.net<br>> > http://postgis.refractions.net/mailman/listinfo/postgis-users<br>> <br>> -------------- next part --------------<br>> An HTML attachment was scrubbed...<br>> URL: <http://postgis.refractions.net/pipermail/postgis-users/attachments/20110508/b906cbd6/attachment-0001.html><br>> <br>> ------------------------------<br>> <br>> Message: 10<br>> Date: Sun, 8 May 2011 10:32:57 -0400<br>> From: Stephen Frost <sfrost@snowman.net><br>> Subject: Re: [postgis-users] Geocoder (from extras)<br>> To: PostGIS Users Discussion <postgis-users@postgis.refractions.net><br>> Message-ID: <20110508143257.GZ4548@tamriel.snowman.net><br>> Content-Type: text/plain; charset="us-ascii"<br>> <br>> * Paragon Corporation (lr@pcorp.us) wrote:<br>> > I'm not sure how much preplanning will help. Because plans are cached in<br>> > PostgreSQL for these dynamic like queries and I think they are actually<br>> > cached across sessions using shared memory. So upping shared memory helps<br>> > quite a bit.<br>> <br>> We're using execute though, so the main query isn't cache'd at all..<br>> <br>> Stephen<br>> -------------- next part --------------<br>> A non-text attachment was scrubbed...<br>> Name: not available<br>> Type: application/pgp-signature<br>> Size: 198 bytes<br>> Desc: Digital signature<br>> URL: <http://postgis.refractions.net/pipermail/postgis-users/attachments/20110508/f25d09ac/attachment-0001.bin><br>> <br>> ------------------------------<br>> <br>> Message: 11<br>> Date: Sun, 8 May 2011 10:36:37 -0400<br>> From: Stephen Frost <sfrost@snowman.net><br>> Subject: Re: [postgis-users] Geocoder (from extras)<br>> To: PostGIS Users Discussion <postgis-users@postgis.refractions.net><br>> Message-ID: <20110508143637.GA4548@tamriel.snowman.net><br>> Content-Type: text/plain; charset="us-ascii"<br>> <br>> Stephen,<br>> <br>> * Stephen Woodbridge (woodbri@swoodbridge.com) wrote:<br>> > In a geocoder I wrote in 2000, I mapped city, state and/or zipcode<br>> > into a list of counties, then only searched those counties. This<br>> > greatly reduced the 3300 counties in Tiger to a small handful that<br>> > needed to be searched. The FIPS-4 document has a mapping of all<br>> > place names to counties. Zipcodes are easier to handle because you<br>> > can just index the records with zipcodes but if you wanted to widen<br>> > the search, then map the zipcode to a place name and then to<br>> > counties.<br>> <br>> Yeah, the geocoder does something similar to this (as I recall, we<br>> create a list of zip codes to scan through, since that's indexed and the<br>> tables aren't stored per-county in my setup).<br>> <br>> Thanks,<br>> <br>> Stephen<br>> -------------- next part --------------<br>> A non-text attachment was scrubbed...<br>> Name: not available<br>> Type: application/pgp-signature<br>> Size: 198 bytes<br>> Desc: Digital signature<br>> URL: <http://postgis.refractions.net/pipermail/postgis-users/attachments/20110508/b3ca5f09/attachment-0001.bin><br>> <br>> ------------------------------<br>> <br>> Message: 12<br>> Date: Sun, 8 May 2011 13:14:28 -0400<br>> From: "Paragon Corporation" <lr@pcorp.us><br>> Subject: Re: [postgis-users] Geocoder (from extras)<br>> To: "'PostGIS Users Discussion'"<br>> <postgis-users@postgis.refractions.net><br>> Message-ID: <8FE3787DA8AA4F8085E4CF34AD9F571D@J><br>> Content-Type: text/plain; charset="us-ascii"<br>> <br>> Yah it does. Though I think I did break it out for simplicity because they<br>> were no longer updating that zip500 or whatever that file was on census<br>> anymore. So I opted to store in separate state schemas and build<br>> differently. I'm not sure that adds much overhead anyway.<br>> <br>> One thing I did notice with the code which we are cleaning up is that all<br>> the functions come in as VOLATILE because they have no markers on them.<br>> Most should be STABLE or IMMUTABLE. Also some functions that should have<br>> been implemented as SQL were implemented as plpgsql.<br>> <br>> We are changing all of these. This should make most difference with batch<br>> geocoding. Because for example for those small mini queries where you have<br>> all addresses on the same street, that can be cached since they will all use<br>> the same result of that subquery.<br>> <br>> Right now they can't because that piece is marked volatile.<br>> <br>> I've committed some of these changes already, but still need to test on some<br>> large data sets. If anyone wants to help test those out, that would be<br>> create.<br>> <br>> <br>> To upgrade your scripts -- rerun the create_geocode.sql . That will allow<br>> you to keep your data but replace the scripts.<br>> <br>> As far as plans go, some statements are best not cached. That would<br>> probably require some experimentation. <br>> <br>> Steve W. Note that most of the queries are parameterized except I think for<br>> a couple. For those couple I'm not sure it makes sense to plan them since<br>> the plan would be wrong for subsequent. If as you said it you change it to<br>> break out to separate tables wirting 52 someodd queries, then the plan would<br>> be valid.<br>> <br>> Right now I feel the low hanging fruit is the actually cacheability of the<br>> results. <br>> <br>> I'm also noticing the normalize_address takes much longer that I would<br>> expect it to. For some its like 50% of the time. I'm troubleshooting why<br>> that is because that function doesn't touch too many tables (if any) besides<br>> the ones we include and load as part of tiger geocoder.<br>> <br>> Thanks,<br>> Regina<br>> http://www.postgis.us<br>> <br>> <br>> -----Original Message-----<br>> From: postgis-users-bounces@postgis.refractions.net<br>> [mailto:postgis-users-bounces@postgis.refractions.net] On Behalf Of Stephen<br>> Frost<br>> Sent: Sunday, May 08, 2011 10:37 AM<br>> To: PostGIS Users Discussion<br>> Subject: Re: [postgis-users] Geocoder (from extras)<br>> <br>> Stephen,<br>> <br>> * Stephen Woodbridge (woodbri@swoodbridge.com) wrote:<br>> > In a geocoder I wrote in 2000, I mapped city, state and/or zipcode <br>> > into a list of counties, then only searched those counties. This <br>> > greatly reduced the 3300 counties in Tiger to a small handful that <br>> > needed to be searched. The FIPS-4 document has a mapping of all place <br>> > names to counties. Zipcodes are easier to handle because you can just <br>> > index the records with zipcodes but if you wanted to widen the search, <br>> > then map the zipcode to a place name and then to counties.<br>> <br>> Yeah, the geocoder does something similar to this (as I recall, we create a<br>> list of zip codes to scan through, since that's indexed and the tables<br>> aren't stored per-county in my setup).<br>> <br>> Thanks,<br>> <br>> Stephen<br>> <br>> <br>> <br>> <br>> ------------------------------<br>> <br>> _______________________________________________<br>> postgis-users mailing list<br>> postgis-users@postgis.refractions.net<br>> http://postgis.refractions.net/mailman/listinfo/postgis-users<br>> <br>> <br>> End of postgis-users Digest, Vol 109, Issue 8<br>> *********************************************<br> </body>
</html>