Sorry, I've been out for a while. I can finally get an example done this week. However, thinking more about it, a fundamental question is whether to support multiple spatial locations per record. For example, a single record could be represented by 3 or 4 points, all of which get filtered together and same balloon info window when clicked.
If multiple locations are supported, then I think separate fields could be appropriate for distinguishing among points, lines, polygons. How else would we distinguish between a line from a series of points, or a closed loop line from a polygon? Or, keep all the data in the same field and use a conditional statement based on another field (i.e., a field that simple states what geometry or data source that record represents.) If multiple locations are NOT supported, then everything could be kept in the same field and the type can be determined by the nature of the data. For example, 1) a single coordinate is a point 2) a series of coordinates with duplicate first/last points is a polygon 3) a series of coordinates with different first/last points is a line (not for closed loops) 4) a link ending in .kml is KML 5) a link ending in .rss/.georss/.xml is GeoRSS As an aside, do you think it's reasonable (coding effort, performance) to support CSV or TXT file input, similar to KML? CSV is a common format to support basic spatial data. Not an issue for points but could be very helpful when managing lines or polygons with dozens or more coordinate pairs. - John Marko wrote: > 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 -~----------~----~----~----~------~----~------~--~---
