Here is a sample Exhibit JSON feed I am using based on a publication database. As of now, it has 41 records: 29 points, 9 polygons, 1 line, 2 KML files (each KML file contains only 1 polygon.)
Dev Feed: http://dev.dgs.udel.edu/pubfeed-json Dev Exhibit: http://dev.dgs.udel.edu/publications The field name containing the coordinates and KML links is: field_maploc_value **Please Note** This is a site very much in development. It's usually restricted but I just opened it up for testing, temporarily. Each record only contains one value. Meaning, each record represents only a single point, polygon, line, or KML file. So, more information would be needed if Exhibit supported multiple values per record (how would you tell a series of points vs a single line?) (The KML files may contain multiple locations and multiple geometries but that's another story!) - 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 ************************************************** 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 -~----------~----~----~----~------~----~------~--~---
