Hey John, Do you have an example already?
-- Regards, Marko On Mar 30, 5:35 am, John Callahan <[email protected]> wrote: > 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? > > - backgroundKMLsources (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 theKML. TheKMLfile 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,KMLworks 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 > >> singleKMLfile then editing a full data array. And with data coming > >> from multiple users, uploading aKMLfile 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 supportKMLfiles in Exhibit (which > >>>> essentially viewsKMLas a distinct data source and container of items), > >>>> I'd like to look at it from another perspective. > > >>>> Why can't we supportKMLsimply 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 supportsKMLand 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 knowKMLcan 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 inKML/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 wholeKMLsources onto the map can be supported, but then > >>> Exhibit cannot filter individual markers, polylines, and polygons added > >>> by theKMLsources. 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 -~----------~----~----~----~------~----~------~--~---
