Sure. I'll put something together in the next couple of days. It will probably be based on example #1 (publication exhibit) from my last email. I have more control over the data sources in that one.
- 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, > > 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 -~----------~----~----~----~------~----~------~--~---
