Yes, this is what I am meaning.  In many cases, I do not want to filter 
within the KML.  The KML file can be treated in the same way as a 
lat/long coordinate pair or polygon bounding box for a single item.  In 
other words, as just another attribute.  Here are two projects I am 
working on right now to illustrate the point.  I will use these to write 
up something on the new wiki.


#1) I'm using Exhibit as a publication database (and of course, 
browse/display tool.)  Each publication has many attributes, including 
title, year, author, keywords, location, etc....  For the location 
field, some pubs cover a single point (like a well), others cover a 
series of points, others cover a region (like a populated town or a 
coastal wetland.)  


#2) I'm building a site concerning environmental research on our coast 
lines.  I like using Exhibit to browse/filter through the site content. 
Some pages talk about hurricanes (lines, paths) that caused significant 
damage.  Some pages focus on data collection stations (points) with time 
series measurements (like temperature, stream flow; a possibility here 
for Timeplot... )    Some pages focus on coastal engineering projects 
that can be all sorts of locations/geometries.


For both projects, KML works great for the storage of geometry, 
especially for display with Google Maps.  Much easier that dealing with 
numerous coordinates. It's also much easier for me to update a single 
KML file then editing a full data array.  And with data coming from 
multiple users, uploading a KML file nearly always works better then 
entering coordinate pairs (for lines, polygons, or multiple points.)


- John

**************************************************
John Callahan
Geospatial Application Developer
Delaware Geological Survey, University of Delaware
227 Academy St, Newark DE 19716-7501
Tel: (302) 831-3584  
Email: [email protected]
http://www.dgs.udel.edu
**************************************************



David Huynh wrote:
> John Callahan wrote:
>   
>> Instead of going through Babel to support KML files in Exhibit (which 
>> essentially views KML as a distinct data source and container of items), 
>> I'd like to look at it from another perspective. 
>>
>> Why can't we support KML simply as a field in the items[] array of an 
>> existing data source?  The same with GeoRSS for that matter.  How about 
>> something simple, like
>>
>> ex:kml = field_name_with_link_to_kml
>> ex:georss = field_name_with_link_to_georss
>>
>> Google Maps supports KML and GeoRSS natively using the GGeoXml()  
>> function.  Take a look at these two examples:
>> http://code.google.com/apis/maps/documentation/examples/geoxml-rss.html
>> http://code.google.com/apis/maps/documentation/examples/geoxml-kml.html
>>
>> To me, this is identical to adding points (GMarker), lines (GPolyline) 
>> and polygons (Gpolygon.)  Ideally, you would like to have any/all of 
>> them displayed on a map at the same time.  That could even be a geotype 
>> or geometery facet..."show me all items that are polygon based" or "show 
>> me all georss feeds."
>>
>>
>> I know KML can be a monster.  It's really a beautiful format as it can 
>> support raw geometry (2d and 3d), cartographic information, and remote 
>> data sources.  The full GeoRSS GML spec also gets complicated.  However, 
>> I believe supporting simple features only in KML/GeoRSS can go a long way.
>>
>>
>> Are there any obvious problems to supporting geo in this way?  I do not 
>> know the Exhibit code so this method may not even be possible.
>>   
>>     
> Loading whole KML sources onto the map can be supported, but then 
> Exhibit cannot filter individual markers, polylines, and polygons added 
> by the KML sources. This is because the data must be homogenized into 
> Exhibit's database in order for Exhibit's filtering mechanism to process 
> it. (We can still support filtering by whole sources.) Is this what you 
> want?
>
> David

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"SIMILE Widgets" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/simile-widgets?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to