Hi Mifan, can you make more examples of your wortkflow for different data types? You tend to make examples just with remote services and I want to make sure all the different types have a proper way to be handled.
What would happen for example with: - shapefiles - folder of shapefiles - tiff - asc - folder with tiff and asc - folder with tiff and shapefiles - postgis connection - no4j connection (or H2 or sqlite) -... any other thought? I can be around for IRC for about 1/2 an hour at the same time as last time. Ciao, Andrea On Tue, Jun 14, 2011 at 10:22 PM, Mifan Careem <[email protected]> wrote: > HI All, > Based on the last IRC breakout on the Catalog View, I've come up with a 2nd > draft of a possible view: > http://udig.refractions.net/confluence/display/UDIG/GSoC+2011+-+Catalog+View+Reports#GSoC2011-CatalogViewReports-catalogscenario1 > Scenario 1 here is trying to keep it as simple as possible, before moving to > the multi-select (scenario 2) and configurable start components (scenario > 3). I'd love to hear your thought on this and verify whether the thinking > here is right. The use case for Scenario 1 is as follows: > > The catalog lists the Service Types (File, Database, Web Services, Other, > Decorator). The other components (Service, DataType and Layers) are blank > User selects the Web Services Service Type > The Services component is then filled with the Services that fall under the > selected Services Type (FGDC WMS, ESRI WMS, Geoserver WFS etc.) > The user selects the MassGIS WFS. This populates the DataType component with > the FeatureTypes. > The user select the FeatureType. This loads the Layers relevant to the > feature type. Usually this might be a 1:1 mapping > > Should we have another IRC to discuss this further? > Cheers > Mifan > On Tue, Jun 7, 2011 at 6:32 PM, Jody Garnett <[email protected]> wrote: >> >> Hi Mifan: >> Sorry for joining the conversation late :-) I am very enthusiastic about >> your work - and also your questions as they will help motivate me to iron on >> the wrinkles in the catalog api. >> >> Services -> Layer -> Type >> This is from Jody's original proposal. >> Services would be a list of services that are loaded >> Layers would be the layers >> Types would be the types of layers >> (An image is available in [2] named Version 3, under the June 10 Weekly >> Report) >> >> Small clarification; I was not sure what to really do for the last column >> as i had a number of "things" I wanted to communicate: >> - type (as you indicated); the annoying part is that type forms a "tree" >> (with the vast majority of types simply extending feature) >> - style (I have a change proposal I need to sort out on this topic; but >> basically styles are organised by feature type - as feature type indicates >> what geometry and attributes are available to be drawn) >> - friends (if the data was available via another service we consider both >> layers to be "friends"). This is actually an "association" but friends makes >> udig a more user-friendly experience :P >> _______________________________________________ >> User-friendly Desktop Internet GIS (uDig) >> http://udig.refractions.net >> http://lists.refractions.net/mailman/listinfo/udig-devel >> > > > _______________________________________________ > User-friendly Desktop Internet GIS (uDig) > http://udig.refractions.net > http://lists.refractions.net/mailman/listinfo/udig-devel > > _______________________________________________ User-friendly Desktop Internet GIS (uDig) http://udig.refractions.net http://lists.refractions.net/mailman/listinfo/udig-devel
