jamess (1) [Avatar] Offline
#1
Hi,

I have a question about the Paris inheritance example. I have worked through the examples in the book.

Is it correct that the parent Paris table does not get listed in the geometry_columns table, but all the child tables do? Or is this missing from the code examples? Or is it not supposed to be listed in this table?

I cant see populate_geometry_columns for this table anywhere in the code examples anywhere in listing 3.5.

QGIS still finds it and opens it.

James
regina.leo (265) [Avatar] Offline
#2
Re: Chapter 3 - Inheritance
To be honest we hadn't given much thought to the geomtry_columns table for this example. A table gets registered in geometry_columns when you use
AddGeometryColumn to create the geometry column or you use probe_geometry_columns or populate_geometry_columns against an existing.

There are 2 reasons we really didn't bother focusing on it
1) Many applications don't need it (e.g. as you noted Quantum doesn't need it though it does speed things up a bit if you have a lot of tables and don't know which table you are looking for). If you create an app for yourself for example just focused on statistics based on space, you won't need it since you'll go straight for the tables and your app would probably be based on derivatives of your geometries.

2) In later versions of PostGIS (might not make it into 2.0 but most definitely 2.1), the way you create geometry columns will be much like the way you create geography columns using the typmod functionality built-it into PostgreSQL (geography was a star child so to speak). This will mean that geometry_columns will become a view that inspects the underlying PostgreSQL system tables and views and the original geometry_columns table will be renamed -- to be tacked on the new view just for legacy tables -- kind of like our caecum that slowly shrunk in size.

Hope that answers your question.
Gyula_58 (13) [Avatar] Offline
#3
Re: Chapter 3 - Inheritance
Hi,

I suspect the ar_num attribute must be involved into the command for starting the dynamic trigger example and should be read something like:
INSERT INTO ch03.paris(osm_id,ar_num, geom, tags)
SELECT osm_id,ar_num, geom, tags FROM ch03.paris_hetero;

There is a reference of NEW.ar_num in the trigger function (listing 3.11), that does not have any value otherwise, and keeps throwing error messages.


Also, I have to remark the data from OpenStreetMap and GeoCommon web sites for the Paris area proved to be topologically incorrect that made very difficult to go through this chapter. It may be considered to attach tested data as well...

Thanks,
Gyula
regina.leo (265) [Avatar] Offline
#4
Re: Chapter 3 - Inheritance
Gyula,

Yes you are right. I checked the latest working version we have and that error has already been corrected in it. Unfortunately that verson isn't on MEAP. I'm not sure there will be a MEAP release before the final proof since we are in the proofing/typesetting stage. If you do come across any more of these, please let us know and hopefully we can get them in before final proof is complete.

What kind of errors did you run into with the dataset? Did you try the data packaged in the ch03_data.sql to see if it had similar issues?

http://www.postgis.us/downloads/ch03_code_data.zip

Thanks,
Leo and Regina
Gyula_58 (13) [Avatar] Offline
#5
Re: Chapter 3 - Inheritance
Hi Leo and Regina,

I downloaded data from the web sites directly, myself. My comment applies for that and by no means for your data set which I have not known about...
Sorry, and please ignore my last words then.

Regards,
Gyula