FW: [Mapserver-users] RE: Topozone in the news ..
Bob Basques
bob.basques at ci.stpaul.mn.us
Tue Dec 9 16:55:01 EST 2003
--------------030502030107090002000408
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Tom,
Geez, I need to check the OpenGIS site more often, this would be exactly
what I was thinking about as far as cached services and distribution
alternatives. I even have an example of it to point too,
While the data is not being directly served from Mapserver, Mapserver
was used for a generation of a couple of the gridded tile sets. FME and
AutoCAD along with PERL were used as well.
For anyone interested:
http://pwultra5.ci.stpaul.mn.us/cgi-bin/drill/ped.02.pl
(NOTE: Not complete yet, I don't know when I'll get back to it, the
Zoom-out function doesn't work yet for example. There are Javascript
errors as well.)
Just pick a point on the image to begin. All should be self explantory
after that. I still need to build the Printing interface as well.
Drill down a couple of levels to see additional Themes become visible.
This is experimental, but is already being used in-house by many folks.
While it's fairly slow over a dialup connection, it works really nicely
in our office network, and gives the users some very basic lookup
capabilities, The service is also hooked into some other services such
as address lookups for example. The data is entirely cached on the
server, with a short PERL CGI to filter the tiles sent to the client.
This can also be built into the clint HTML as a JAVASCRIPT operation,
where the server is simply a container for the data.
This service is entirely Raster with a high dependency on transparent
PNGs. I had though about SVG on top of this for Vector data
distribution where required, GPS tracking for example.
It's interesting that the link you sent is promoting a DYNAMIC service
type of call. For example, the data for the service capabilities could
just as easily be static in nature, an XML page per theme for example.
A basic hierarchy for storage could work jsut as esily I think. Where
a simple standard could be implemented as a catalog service type. Maybe
an optional service type could be used vs the CGI (callable version).
These are just some thoughts on the subject. I think I'm starting to
veer off of the Mapserver List subject matter however. I don't know of
a recourse for these thoughts at this time however. :c)
bobb
Kralidis,Tom [Burlington] wrote:
>
>>-----Original Message-----
>>From: bob.basques at ci.stpaul.mn.us
>>[mailto:bob.basques at ci.stpaul.mn.us]
>>Sent: Tuesday, December 09, 2003 3:02 PM
>>To: mapserver-users at lists.gis.umn.edu
>>Subject: Re: FW: [Mapserver-users] RE: Topozone in the news ..
>>
>>
>>All,
>>
>>This topic has been interesting to follow. I have a couple
>>of comments
>>on it.
>>
>>I'm wondering about alternative forms of service, still web based
>>though. Certain aspects of mapping data distribution can be improved
>>with a variety of caching techniques for example, to name one, among
>>many. what would be the best way to demonstrate/relate
>>these types of
>>ideas to this partnership. I would assume that one or bo
>>th would be
>>interested in hearing from the general user base.
>>
>
>w.r.t. data distribution (download), this sounds like a good fit for the OGC
>Web Coverage Service (WCS) implementation specification
>(http://www.opengis.org/docs/03-065r6.pdf), which, from what I hear, will be
>implemented and supported by MapServer. Is there any ETA on this
>functionality?
>
>..Tom
>
>
>>What would a partnership such as this be interested in as far as
>>feedback from the user communities if at all. Should these idea
>>related specifically to Mapserver (for this list) or is there another
>>forum for such conversations in place somewhere? I didn't
>>find anything
>>specifically related.
>>
>>Thanks
>>
>>
>>
>>bobb
>>
>> >
>>
>>
>>
>>_______________________________________________
>>Mapserver-users mailing list
>>Mapserver-users at lists.gis.umn.edu
>>http://lists.gis.umn.edu/mailman/listinfo/mapserver-users
>>
>
--------------030502030107090002000408
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<html>
<head>
</head>
<body>
Tom,<br>
<br>
<br>
Geez, I need to check the OpenGIS site more often, this would be exactly
what I was thinking about as far as cached services and distribution alternatives.
I even have an example of it to point too,<br>
<br>
While the data is not being directly served from Mapserver, Mapserver was
used for a generation of a couple of the gridded tile sets. FME and AutoCAD
along with PERL were used as well.<br>
<br>
For anyone interested:<br>
<br>
<a class="moz-txt-link-freetext" href="http://pwultra5.ci.stpaul.mn.us/cgi-bin/drill/ped.02.pl">
http://pwultra5.ci.stpaul.mn.us/cgi-bin/drill/ped.02.pl</a>
<br>
<br>
(NOTE: Not complete yet, I don't know when I'll get back to it, the Zoom-out
function doesn't work yet for example. There are Javascript errors as well.)<br>
<br>
Just pick a point on the image to begin. All should be self explantory
after that. I still need to build the Printing interface as well. Drill
down a couple of levels to see additional Themes become visible.<br>
<br>
<br>
This is experimental, but is already being used in-house by many folks.
While it's fairly slow over a dialup connection, it works really nicely
in our office network, and gives the users some very basic lookup capabilities,
The service is also hooked into some other services such as address lookups
for example. The data is entirely cached on the server, with a short PERL
CGI to filter the tiles sent to the client. This can also be built into the
clint HTML as a JAVASCRIPT operation, where the server is simply a container
for the data.<br>
<br>
This service is entirely Raster with a high dependency on transparent PNGs.
I had though about SVG on top of this for Vector data distribution where
required, GPS tracking for example.<br>
<br>
It's interesting that the link you sent is promoting a DYNAMIC service type
of call. For example, the data for the service capabilities could just as
easily be static in nature, an XML page per theme for example. A basic hierarchy
for storage could work jsut as esily I think. Where a simple standard could
be implemented as a catalog service type. Maybe an optional service type
could be used vs the CGI (callable version). These are just some thoughts
on the subject. I think I'm starting to veer off of the Mapserver List subject
matter however. I don't know of a recourse for these thoughts at this time
however. :c)<br>
<br>
<br>
bobb<br>
<br>
<br>
<br>
Kralidis,Tom [Burlington] wrote:<br>
<blockquote type="cite" cite="mid:2576812186CDD411BF1500508B6DCE9505D492D9 at ECNWRI1.ontario.int.ec.gc.ca">
<pre wrap=""><br></pre>
<blockquote type="cite">
<pre wrap="">-----Original Message-----<br>From: <a class="moz-txt-link-abbreviated" href="mailto:bob.basques at ci.stpaul.mn.us">bob.basques at ci.stpaul.mn.us</a> <br>[<a class="moz-txt-link-freetext" href="mailto:bob.basques at ci.stpaul.mn.us">mailto:bob.basques at ci.stpaul.mn.us</a>] <br>Sent: Tuesday, December 09, 2003 3:02 PM<br>To: <a class="moz-txt-link-abbreviated" href="mailto:mapserver-users at lists.gis.umn.edu">mapserver-users at lists.gis.umn.edu</a><br>Subject: Re: FW: [Mapserver-users] RE: Topozone in the news ..<br><br><br>All,<br><br>This topic has been interesting to follow. I have a couple <br>of comments<br>on it.<br><br>I'm wondering about alternative forms of service, still web based<br>though. Certain aspects of mapping data distribution can be improved<br>with a variety of caching techniques for example, to name one, among<br>many. what would be the best way to demonstrate/relate <br>these types of<br>ideas to this partnership. I would assume that one or bo
th would be<br>interested in hearing from the general user base.<br><br></pre>
</blockquote>
<pre wrap=""><!----><br>w.r.t. data distribution (download), this sounds like a good fit for the OGC<br>Web Coverage Service (WCS) implementation specification<br>(<a class="moz-txt-link-freetext" href="http://www.opengis.org/docs/03-065r6.pdf">http://www.opengis.org/docs/03-065r6.pdf</a>), which, from what I hear, will be<br>implemented and supported by MapServer. Is there any ETA on this<br>functionality?<br><br>..Tom<br><br><br></pre>
<blockquote type="cite">
<pre wrap="">What would a partnership such as this be interested in as far as<br>feedback from the user communities if at all. Should these idea<br>related specifically to Mapserver (for this list) or is there another<br>forum for such conversations in place somewhere? I didn't <br>find anything<br>specifically related.<br><br>Thanks<br><br><br><br>bobb<br><br> ><br><br><br><br>_______________________________________________<br>Mapserver-users mailing list<br><a class="moz-txt-link-abbreviated" href="mailto:Mapserver-users at lists.gis.umn.edu">Mapserver-users at lists.gis.umn.edu</a><br><a class="moz-txt-link-freetext" href="http://lists.gis.umn.edu/mailman/listinfo/mapserver-users">http://lists.gis.umn.edu/mailman/listinfo/mapserver-users</a><br><br></pre>
</blockquote>
<pre wrap=""><!----><br></pre>
</blockquote>
<br>
<br>
</body>
</html>
--------------030502030107090002000408--
More information about the mapserver-users
mailing list