[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[udig-devel] Re: [Mapbuilder-devel] Re: OWS Spec?
|
Quoting Allan Doyle <adoyle@xxxxxxxxx>:
>
> On Mar 21, 2006, at 09:52, Pat Cappelaere wrote:
>
> > Tom,
> >
> > We have considered this but our driving force is to be able to save
> > all map
> > elements in a context that can be saved and send/share it to
> > someone else.
> > Does this make sense? If not, we would have to look at an
> > alternate way...
>
> I think you have to consider the desired result in light of whether
> you're setting up a mini-standard for mapbuilder/udig or whether you
> want to set up a standard that all mapping apps can share.
>
> Right now it seems to me that since there is no standard way to layer
> yahoo/google/etc maps into a stack of layers, that you're really
> doing the former, not the latter.
I think this is what we are hoping to set up? An the OWS Context document is
close, but even in the OWS-3 project we encountered difficulty in extending it
for additional data types.
The other issues was one of failover, defining several sources of information
for a layer - incase a server is down. The difference in the OWS-3 demo for
uDig vs GeoTango was an education for me with respect to this use case.
> Therefore, it makes sense to consider a yahoo layer or a google layer
> to be at the same level as a WMS Context in your saved file. I.e you
> should make a context that looks like this:
>
> <mbudigcontext>
> <yahoolayer>...</yahoolayer>
> <wmscontext> ... embed WMS Context here ... </wmscontext>
> ... etc ...
> </mbudigcontext>
>
I think we want to embed the other data types into the same zorder as the
normal OWS layers. Cameron started this conversation with me, so there is at
least two products that are interested.
<spatialcontext>
<viewport and projection/>
<layer><wms1><wms2><wfs3></layer>
<layer><wms2><custom1></layer>
</spatialcontext>
The important part to capture is the viewport and projection, the zorder of
the layers and the source of data (both ows based and custom).
Thanks for your time Allan and Tom I will go and register for the sub project.
Jody
> If you do the inverted thing of embedding other oddball layers into
> the WMS context, you violate the principle that says things should
> work as similarly as possible in all apps since some apps won't be
> able parse the oddball stuff. That's not interoperability.
>
> This would all be easier if GY(M) were to allow for standard layer
> access. (M) is providing WMS, I think.
>
> If you want to be able to have points in the context that can be
> layered (mashed, actually) into GYM maps, then that's a different
> thing. You can use GeoRSS or GML and it might be very interesting to
> talk about adding GeoRSS or GML to WMS Context or OWS Context
> Allan
>
>
> > Thanks again.
> > Pat.
> >
> >
> >> From: "Kralidis,Tom [Burlington]" <Tom.Kralidis@xxxxxxxx>
> >> Date: Tue, 21 Mar 2006 09:34:17 -0500
> >> To: "Shorter, Cameron" <cameron.shorter@xxxxxxxxxxxxxxx>, Jody
> >> Garnett
> >> <jgarnett@xxxxxxxxxxxxxxx>
> >> Cc: <mapbuilder-devel@xxxxxxxxxxxxxxxxxxxxx>, User-friendly
> >> Desktop Internet
> >> GIS <udig-devel@xxxxxxxxxxxxxxxxxxxxx>, Allan Doyle
> >> <adoyle@xxxxxxxxx>
> >> Conversation: [Mapbuilder-devel] Re: OWS Spec?
> >> Subject: RE: [Mapbuilder-devel] Re: OWS Spec?
> >>
> >>
> >> All,
> >>
> >> I appreciate the need for integrating more resource types in a
> >> boorkmarkable-state. Having said this, have you considered
> >> standardizing (defacto) your application-specific configurations (as
> >> Allan Doyle suggested in an offline discussion)? For example,
> >> Mapbuilder has it's own XML config which uses WMC by pointing to it.
> >> So why not put your non WMC or OWSContext types in those
> >> configurations
> >> and share those?
> >>
> >> Cheers
> >>
> >> ..Tom
> >>
> >>
> >>> -----Original Message-----
> >>> From: Shorter, Cameron [mailto:cameron.shorter@xxxxxxxxxxxxxxx]
> >>> Sent: Tuesday, March 21, 2006 2:08 AM
> >>> To: Kralidis,Tom [Burlington]; Jody Garnett
> >>> Cc: mapbuilder-devel@xxxxxxxxxxxxxxxxxxxxx; User-friendly
> >>> Desktop Internet GIS
> >>> Subject: RE: [Mapbuilder-devel] Re: OWS Spec?
> >>>
> >>>
> >>> Tom, thankyou for this email.
> >>>
> >>> I agree with the aim of a having a standard is to get all
> >>> products (like Google Maps) to conform to a set standard
> >>> instead of changing a standard to fit to all the different vendors.
> >>>
> >>> As I see it, there is a new type of Mapping server that has
> >>> been popularised by Google/Yahoo/MSN etc which is based on a
> >>> set of finite tiles of maps with fixed sizes and zoom levels.
> >>> This type of server is very useful for a certain set of
> >>> business cases and the OGC should define a standard API for
> >>> these services. Eg, set tile size, projection, zoom level
> >>> etc.. We then should be pushing for Google/Yahoo/MSN to
> >>> adopt the API.
> >>>
> >>> We can then reference the "TiledServer" as a layer in the OWS doc.
> >>>
> >>> I notice that Google is now an OGC member, maybe they could
> >>> be tempted to sponsor this activity.
> >>>
> >>> The other Layer type which I think is ready to be
> >>> incorporated now is a GeoRSS layer (as I understand that a
> >>> GeoRSS spec already exists).
> >>>
> >>>> -----Original Message-----
> >>>> From: mapbuilder-devel-admin@xxxxxxxxxxxxxxxxxxxxx
> >>>> [mailto:mapbuilder-devel-admin@xxxxxxxxxxxxxxxxxxxxx] On
> >>>> Behalf Of Kralidis,Tom [Burlington]
> >>>> Sent: Tuesday, 21 March 2006 1:57 AM
> >>>> To: Jody Garnett; Cameron Shorter
> >>>> Cc: mapbuilder-devel@xxxxxxxxxxxxxxxxxxxxx; User-friendly
> >>>> Desktop Internet GIS
> >>>> Subject: RE: [Mapbuilder-devel] Re: OWS Spec?
> >>>>
> >>>>
> >>>> Hi,
> >>>>
> >>>> Jody: I'm not sure that having vendor specific extensions at
> >>>> the FeatureType/Layer/Coverage level would be appropriate for
> >>>> non-OGC specifications.
> >>>>
> >>>> The idea of OWSContext is/would be to capture the state of a
> >>>> given application in relation to what OGC specifications are used.
> >>>>
> >>>> In the early WMC days, we had similar requirements where some
> >>>> vendors desired vendor specific extensions which enabled some
> >>>> functionality on their systems. These extensions were items
> >>>> which may have enhanced the way their WMS worked, for
> >>>> example. As a result, we added an ExtensionType of xs:any
> >>>> (some people call this 'fairy dust') to the WMC Layer element
> >>>> to satisfy this requirement. Everything within this
> >>>> Extension was a 'free for all', and had no definition. It
> >>>> was expected that this would be used by specific information
> >>>> communities, with the underlying structure to be
> >>>> defined/agreed upon by them.
> >>>>
> >>>> So what we have in WMC, and in OWSContext is an Extension, which
> >>>> *extends* a known OGC resource type. What (I think) you're
> >>>> looking for in OWSContext are capabilities for new resource types.
> >>>>
> >>>> Having said this, adding new resource types and defs for
> >>>> Google, Yahoo, etc. in OWSContext concerns me. If we start
> >>>> adding <insert waycool mapping api of the month> new types of
> >>>> resources, then OWSContext becomes a very generic web mapping
> >>>> bookmark. With many different ways to connect to maps. And
> >>>> then clients are full of specific plug-ins for specific
> >>>> webmap bindings. And then we'll look to some standards body
> >>>> to harmonize things because we have so much variation.
> >>>>
> >>>> I'm overdoing it here, I know. However I'd rather see Google
> >>>> Maps type APIs officially recognized by OGC before making
> >>>> specification changes.
> >>>>
> >>>> There's no reason you can't (for now) use OWSContext and
> >>>> either shoehorn Google Maps into a Layer element, with agreed
> >>>> upon extensions or (gulp) come up with your own agreed-upon
> >>>> resource type for Google Maps and use it. For non-validating
> >>>> XML parsers, your Google Maps resource type would probably be
> >>>> skipped as it's looking for Layer/Coverage/FeatureType.
> >>>> You'll run into problems with validating XML parsers because
> >>>> it's not defined in the schema.
> >>>>
> >>>> My $0.02. I'd be interested in hearing comments and other
> >>> viewpoints.
> >>>>
> >>>> ..Tom
> >>>>
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: mapbuilder-devel-admin@xxxxxxxxxxxxxxxxxxxxx
> >>>>> [mailto:mapbuilder-devel-admin@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of
> >>>>> Jody Garnett
> >>>>> Sent: Saturday, March 18, 2006 6:49 PM
> >>>>> To: Cameron Shorter
> >>>>> Cc: 'mapbuilder-devel@xxxxxxxxxxxxxxxxxxxxx'; Kralidis,Tom
> >>>>> [Burlington]; User-friendly Desktop Internet GIS
> >>>>> Subject: [Mapbuilder-devel] Re: OWS Spec?
> >>>>>
> >>>>>
> >>>>> Cameron Shorter wrote:
> >>>>>> Jody, mapbuilder,
> >>>>>>
> >>>>>> I'm planning to integrate a Google Maps layer into our
> >>>> OWS document
> >>>>>> and would like to know what format it should take.
> >>>>>>
> >>>>>> 1. Is there an OWS Spec of schema?
> >>>>> Yes, and you can find a copy of it in the uDig OWS3
> >>>> project:, looking.
> >>>>> We put the context support on trunk here:
> >>>>> - http://svn.geotools.org/udig/trunk/plugins/net.refractions.udi
> >>>> g.context/
> >>>>
> >>>> I could not see the actual schema file in there, however
> >>>> talking to Tom will get you something newer.
> >>>>> 2. How should we describe a GoogleMaps layer within an OWS doc?
> >>>>> (Ideally we should also think about YahooMaps, MSN Maps,
> >>>> etc and treat
> >>>>
> >>>>> them in a similar manner).
> >>>> Indeed we need to treat any vendor specific thing in a
> >>> similar manner.
> >>>>
> >>>> We need to talk to Tom and get him to put in a vendor
> >>>> specific extension
> >>>>
> >>>> at the same level as Layer, FeatureType and Coverage. I asked
> >>>> him back in November and have not heard of any progress
> >>>> (yet). That said I have not joined that working group either.
> >>>>
> >>>> How about it Tom, we have a couple of communities that want
> >>>> to use your schema to communicate?
> >>>> Jody
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> -------------------------------------------------------
> >>>> This SF.Net email is sponsored by xPML, a groundbreaking scripting
> >>>> language that extends applications into web and mobile
> >>> media. Attend
> >>>> the live webcast and join the prime developer group
> >>> breaking into this
> >>>> new coding territory!
> >>>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&;
> >>>> dat=121642
> >>>> _______________________________________________
> >>>> mapbuilder-devel mailing list mapbuilder-
> >>>> devel@xxxxxxxxxxxxxxxxxxxxx
> >>>> https://lists.sourceforge.net/lists/listinfo/mapbuilder-devel
> >>>>
> >>>>
> >>>> -------------------------------------------------------
> >>>> This SF.Net email is sponsored by xPML, a groundbreaking
> >>>> scripting language
> >>>> that extends applications into web and mobile media. Attend
> >>>> the live webcast
> >>>> and join the prime developer group breaking into this new
> >>>> coding territory!
> >>>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&;
> >>>> dat=121642
> >>>> _______________________________________________
> >>>> mapbuilder-devel mailing list
> >>>> mapbuilder-devel@xxxxxxxxxxxxxxxxxxxxx
> >>>> https://lists.sourceforge.net/lists/listinfo/mapbuilder-devel
> >>>>
> >>>
> >>>
> >>> DISCLAIMER:---------------------------------------------------
> >>> ------------------------
> >>> This Email may contain confidential and/or privileged
> >>> information and is intended
> >>> solely for the addressee(s) named. If you have received this
> >>> information in error, or
> >>> are advised that you have been posted this Email by accident,
> >>> please notify the
> >>> sender by return Email, do not redistribute it, delete the
> >>> Email and keep no copies.
> >>> --------------------------------------------------------------
> >>> ------------------------
> >>>
> >>
> >>
> >> -------------------------------------------------------
> >> This SF.Net email is sponsored by xPML, a groundbreaking scripting
> >> language
> >> that extends applications into web and mobile media. Attend the
> >> live webcast
> >> and join the prime developer group breaking into this new coding
> >> territory!
> >> http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
> >> _______________________________________________
> >> mapbuilder-devel mailing list
> >> mapbuilder-devel@xxxxxxxxxxxxxxxxxxxxx
> >> https://lists.sourceforge.net/lists/listinfo/mapbuilder-devel
> >
> >
>
> --
> Allan Doyle
> +1.781.433.2695
> adoyle@xxxxxxxxx
>
>
>
>
