[georss] Styling GeoRss points

Stefan F. Keller sfkeller at gmail.com
Mon Jun 4 15:57:55 EDT 2007 

I would avoid to mixin-in styling into GeoRSS. And restricting to points
seems to me unbalanced. If you mix-in KML, why not convert everything into
KML in the first place?

Applying SLD to GeoRSS - as Pat suggested - (while both keeping
apart) sounds promising; or eventually a subset of SLD? Yust my 2 cents

-- Stefan

2007/6/4, Pat Cappelaere <pat at cappelaere.com>:
>
> Charlie,
>
> A good option for you would be to use an OGC compliant client such as
> Community MapBuilder that would allow you to define an OGC SLD (Style
> Layer
> Descriptor) for that feed.
> http://docs.codehaus.org/display/MAP/Home
>
> CMB will generate SVG or VML depending on your browser.
>
> An interesting exercise would be to specify that SLD as an xlink option in
> your GeoRSS feed and get the client to use it.
>
> You can always specify a KML feed too.
>
> Regards,
>
> Pat G. Cappelaere
>
>
> Vightel Corporation
> www.vightel.com
> Cell: 410.340.4868
> Bus: 443.283.0369
> Fax: 443.283.0370
>
>
> > From: "Gregor J. Rothfuss" <gregor at apache.org>
> > Date: Mon, 04 Jun 2007 13:51:34 -0400
> > To: Charlie Savage <cfis at savagexi.com>, "georss at lists.eogeo.org"
> > <georss at lists.eogeo.org>
> > Subject: Re: [georss] Styling GeoRss points
> >
> > Charlie Savage wrote:
> >> Hi everyone,
> >>
> >> I'd like revisit a discussion that happened in January about styling
> >> GeoRss points.  I'd like to specify two images/icons for each Atom
> entry
> >> that has a GeoRss point - a normal image and a hover image for mouse
> overs.
> >>
> >> I'm wondering if there is any community consensus on how to do this?
> >> Doing a bit of research, I found a discussion about this on the GeoRss
> >> mailing list in January. A good starting point is a post by Christopher
> >> Schmidt who talked about reusing KML, while Mikel Maron asked if
> reusing
> >> CSS was more appropriate.
> >>
> >> I agree that styling information shouldn't be added to GeoRss and that
> >> reusing CSS is a good choice. However, CSS doesn't work for points when
> >> you want to represent them with an image/symbol. Based on its HTML
> >> heritage, CSS considers images to be markup and not presentation and
> >> thus does not support changing an image's src attribute. The closest it
> >> gets is supporting background images, but that seems like the wrong
> >> solution for this problem.
> >
> > it appeals to me on a theoretical level, but you'd have to implement a
> > CSS engine with all its cascading rules to do it properly. the only
> > place where that ever happened outside of HTML is SVG and that has been
> > a failure, unfortunately.
> >
> >> Thus, we need to find another solution. Some ideas I've pondered
> include:
> >>
> >> 1. Use KML as Chris suggested. It would look something like this:
> >>
> >> <Style id="highlightPlacemark">
> >>   <IconStyle>
> >>   <Icon>
> >>   <href>http://maps.google.com/mapfiles/kml/paddle/red-stars.png</href>
> >>   </Icon>
> >>   </IconStyle>
> >> </Style>
> >> <Style id="normalPlacemark">
> >>   <IconStyle>
> >>   <Icon>
> >>   <href>http://maps.google.com/mapfiles/kml/paddle/wht-blank.png</href>
> >>   </Icon>
> >>   </IconStyle>
> >> </Style>
> >> <StyleMap id="exampleStyleMap">
> >>   <Pair>
> >>     <key>normal</key>
> >>     <styleUrl>#normalPlacemark</styleUrl>
> >>   </Pair>
> >>   <Pair>
> >>     <key>highlight</key>
> >>     <styleUrl>#highlightPlacemark</styleUrl>
> >>   </Pair>
> >> </StyleMap>
> >>
> >> The obvious downside to this is how verbose it is - which is fine for
> >> KML but doesn't fit the GeoRss philosphy of keeping things simple.
> >
> > verbose yes, complicated no. once you consider the hoops you have to
> > jump through with the other solutions, it balances out sorta ok. i was
> > not around when that piece of KML was designed or this would maybe look
> > something like
> >
> >   <Style id="highlightPlacemark">
> >     <Icon href="http://maps.google.com/mapfiles/kml/paddle/red-stars.png
> "/>
> >   </Style>
> >   <Style id="normalPlacemark">
> >     <Icon href="http://maps.google.com/mapfiles/kml/paddle/wht-blank.png
> "/>
> >   </Style>
> >   <StyleMap id="exampleStyleMap">
> >     <Pair key="normal" href="#normalPlacemark/>
> >     <Pair key="highlight href="#highlightPlacemark/>
> >   </StyleMap>
> >
> > water on the bridge for 2.1/2.2, but maybe something the OGC would like
> > to tackle? making things simpler for a change?
> >
> >> 2. Reuse atom's icon element:
> >>
> >> <atom:icon>http://www.mapbuzz.com/images/marker.gif</atom:icon>
> >> <atom:icon pseudo-class="hover">
> >>     http://www.mapbuzz.com/images/marker_hover.gif</atom:icon>
> >>
> >> The downsides to this approach are:
> >>
> >>     * atom:icon is defined only at the feed level.
> >>     * we have to introduce a custom attribute, which I called
> >> pseudo-class to match CSS's terminology.
> >>     * If Atom ever supports icon at the entry level the semantics
> likely
> >> will be a bit different.
> >>     * atom:icon does not specify widths or heights, which is important
> >> to support SVG symbols.
> >
> > yahoo did that:
> >
> >
> http://feedvalidator.org/check.cgi?url=http%3A%2F%2Fdeveloper.yahoo.net%2Fmaps
> > %2Fsample.xml
> >
> > no comment.
> >
> >> 3. Reuse XHTML's img element:
> >>
> >> <xhtml:img href="http://www.mapbuzz.com/images/marker.gif"
> >>   height="32" width="32"/>
> >> <xhtml:img href="http://www.mapbuzz.com/images/marker.gif"
> >>   height="32" width="32"alt="hover"/>
> >>
> >> The advantage to this approach is that Atom's content element already
> >> allows mixing in of XHTML, so there is some precedence. It also
> supports
> >> image sizes and we could hijack alt to specify different images types.
> >
> > hijacking class or role seems more appropriate.
> >
> >> 4. Reuse SVG's image element:
> >>
> >> <xhtml:img xlink:href="http://www.mapbuzz.com/images/marker.gif"
> >> x="100" y="100"height="32" width="32"/>
> >> <xhtml:img xlink:href="http://www.mapbuzz.com/images/marker.gif"
> >> x="100" y="100"height="32" width="32" pseudo-class="hover"/>
> >>
> >> An SVG image introduces a funny twist - it let's you specify x and y
> >> values.I could see this being confused with the x/y values in a GeoRss
> >> point. Alternatively, it could be helpful to precisely postion this
> >> image. SVG images also support a number of style related attributes,
> >> such as opacity, which could be helpful.
> >
> > xlink? oy. talk about a stillborn standard.
> >
> >> Currently, option #4 looks like the best choice to me, but just
> >> wondering what other people think.
> >
> > from an implementation POV, 1) has the benefit that you are implementing
> > something that you need anyway if you are also supporting KML.
> > _______________________________________________
> > georss mailing list
> > georss at lists.eogeo.org
> > http://lists.eogeo.org/mailman/listinfo/georss
>
>
> _______________________________________________
> georss mailing list
> georss at lists.eogeo.org
> http://lists.eogeo.org/mailman/listinfo/georss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.eogeo.org/pipermail/georss/attachments/20070604/4f859d03/attachment-0001.html 
-------------- next part --------------
_______________________________________________
georss mailing list
georss at lists.eogeo.org
http://lists.eogeo.org/mailman/listinfo/georss

More information about the georss mailing list