John,
Let's work together on this. I do want to unify all of the features into
a single map view, but I need data to make a compelling and realistic
example to test, and to show off the features. Could you please provide
me with data for such an example?
- background KML sources (including points, polylines, and polygons
that make up background landmarks)
- points, polylines, polygons that are items that can be filtered
- properties on those items useful for filtering
In other words, if you can provide me with an exhibit, HTML and data,
the way you want it, I'll try to make it work for real.
David
John Callahan wrote:
> 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
-~----------~----~----~----~------~----~------~--~---
