[mapserver-users] getExtent / setExtent problems

[Puneet Kishor]

Hi Daniel,

On Tuesday, July 31, 2001, at 07:13  PM, Daniel Morissette wrote:

> Puneet Kishor wrote:
>>
>> Anyone, any idea how I can retrieve the row_id for a shape.dbf without
>> actually having to add that as a field?
>>
>
> When you call dbase_get_record() or dbase_get_record_with_names() to
> read a DBF record you have to pass a record_id ... the corresponding
> shapeid is (record_id - 1)
>
> In other words, the shapeids in the .shp files are in the same sequence
> as the records in the DBF... it's just that shapeids start at 0 in
> MapScript, and DBF recordids start at 1 in the PHP dbase module.

Thanks for the explanation. I have to find a work-around though... my 
problem is selecting records from a MySQL table, and using the primary 
key (parcel_id, or tax_id, or whatever_id) to find the associated record 
in the .dbf, get its row number, lookup the shape to get its extent, 
etc. I have decided to load a copy of the dbf into a MySQL table and 
thereby completely bypassing the dbf altogether. Works much better 
except for the minor issue of keeping the dbf and its MySQL copy synced.

Maybe having an Xbase query method in Mapscript (SDL talked of something 
like this in v. 3.5) would alleviate such contortions.

>
>> --
>>
>> a house-keeping question --
>>
>> I find that the messages I post to the mapserver list take several 
>> hours to
>> appear in my email... 5-8 hours delay. Does the mapserver listserver 
>> not
>> broadcast the posted emails immediately? Seems not, so, is it not 
>> possible
>> to do so?
>>
>
> You're not the first one to report this... I'm lucky I'm probably in the
> first 100 in the list and get the messages within 30 minutes but I heard
> of up to 9 hours delays from others too.
>
> I Emailed Steve about this not long ago... and he forwarded my request
> to the list admins but I still have no news.
>
> I never administered a list like this, but perhaps a cleanup of the
> addresses that fail too often could help?  Or perhaps offering a
> daily-digest option (for those who want it) could reduce the load on the
> mail server and help a bit?

As I recall, there are approx. 400 subscribers to the list... that 
should not be a _large_ load. In any case, I would be happy to receive 
mail digest format if that is the only way to get the postings quicker. 
I do get 7-10 hour delays. So, usually I find it better to cc the email 
to the original poster as well (like this one to you). However, if in a 
bind to get an answer quickly, the delay still stinks.


>
>
>> Is it possible to migrate to a web-based forums so we can access the 
>> forums
>> (and not just the archives) from anywhere? I use Cold Fusion driven 
>> forums a
>> lot (Macromedia's CF support forums are on the web), and the Forums 
>> software
>> is open source, although it does require a CF server (I might be able 
>> to
>> convince my company to host 'em). There are other cgi-driven forums as 
>> well.
>>
>
> Please no!!!!!  Unless there is still an option to receive the messages
> and reply by Email.  ;)
> I hate those web-only forums where it takes forever to read and reply to
> a message.  (Of course, that's just my opinion :)

You are absolutely right... but, indeed, there are forums that include 
the email option... I have been developing on Cold Fusion now for half a 
decade, and find the CF support forums invaluable (forums.allaire.com). 
I post on the forum, of course, it is instantaneous. And, I have an 
option of subscribing to that thread. So, all future postings to that 
thread (or to any/all subscribed threads) get emailed to me. In the 
email is embedded a link to the actual post on the web as well. This way 
I have the best of both worlds... immediate posting and response 
(usually all queries get answered within the hour), and I don't even 
have to go to the web site if I don't want to or can't... emails come to 
me.

Right now there is the issue of the delay, of course. In addition, the 
search interface is really cruddy... surely, a threaded interface is 
more attractive and intuitive.

Again, something to think about.

pk/