From: Larson, T. E. <TEL...@we...> - 2006-08-25 20:59:58
|
Alexandre Leroux wrote: > The first feature is adding GeoRSS tags to the RSS feed of the slash > site. You can learn more about on http://georss.org and > http://slashgeo.org/search.pl?query=3Dgeorss. In short, RSS items are > geolocated, meaning they can be mapped or queried by the user. > Example: =20 > show me RSS story items that are within 50 miles of my state. My goal > was simply to have an automated map my slash stories. It works :-) (I > can't show you a map of slashgeo.org's mapped georss feed since I > stopped geocoding stories until feature #2 below stops showing errors > for geolocated stories :-) =20 [snip] > My slash site, slashgeo.org, will definitely use the plugin and > geolocate every story whenever appropriate. Ultimately, people will be > able to browse stories by location, say, stories that relates to the > UK. =20 Hmmm... Slash - Low-Priority Feature Requests, 699051, story regionalization I'd've been happy with a even a list of regions/countries to choose from when submitting stories. How hard is it to reliably map any given coordinate pair to a city/country/state/area? I can certainly see the utility in finding local postings (i.e. "within 200 km of <coord>") but more likely (for my needs) I'd want to focus on "Canada" or "Manhattan" or "Middle East". It certainly would be easier (for non-geography buffs) to submit something like this (i.e. picking from a list, clicking a map region) with stories rather than coordinate pairs. So this only applies to RSS, and you won't notice anything when visiting the site otherwise? If the story has location info, I'd want to see it in the story somewhere. > What's the overhead? Not much. You simply need to specify a location > (latitude / longitude coordinates) for your stories. Does it generate > added-value? Well, to my readers, yes, since we're geospatial > professionals. To your slashsite? You're the judge! :-) =20 I think it would be a huge value-add, and very useful, especially were it given the ability to use "general" location as well as "specific" location. But like I alluded to, I don't know how difficult it would be to piggyback the general on top of the specific. Tim --=20 Tim Larson West Corporation, Interactive TeleServices Eschew obfuscation! |
From: Larson, T. E. <TEL...@we...> - 2006-08-25 21:32:21
|
Alexandre Leroux wrote: > You'll be happy Tim, the GeoRSS standard (it's a Open Geospatial > Consortium standard, see http://www.opengeospatial.org/) allows not > only points, but lines and polygons. So this means, to take your > example, you can specify Canada or Middle-East with a polygon. This is So I'd just have to define my polygons when creating the site, and add this list to the story submit page? Cool. > -already- in the plugin :-) One of the improvements will be to allow > adding and selecting regularly used 'locations' from a list, instead > of having to type the whole coordinates in the story edition page. > This droplist could be provided to users submitting stories. =20 This officially takes you to the top of the "my favorite people" list. :) > I wasn't aware there was previous feature request of story > 'regionalization'. If you ask me, GeoRSS is the way to go, since it is > a standard. =20 Yes, sounds like it! Tim --=20 Tim Larson West Corporation, Interactive TeleServices Eschew obfuscation! |
From: Alexandre L. <ale...@ec...> - 2006-08-28 13:12:06
|
Larson, Timothy E. wrote: > This officially takes you to the top of the "my favorite people" list. > :) It's really Shane (www.lottadot.com) whom should be in your list. He's=20 the one coding and I'm merely annoying him with feature requests ;-) I'll send an update to the list once we have something tangible to show. Have a nice Monday, Alex --=20 Alexandre Leroux, M.Sc., Ing. Environnement Canada / Environment Canada Centre m=E9t=E9orologique canadien / Canadian Meteorological Centre Division de la r=E9ponse aux urgences environnementales / Environmental Emergency Response Division ale...@ec... |
From: shane <sh...@lo...> - 2006-08-29 13:45:07
|
On Aug 28, 2006, at 9:11 AM, Alexandre Leroux wrote: > > > Larson, Timothy E. wrote: >> This officially takes you to the top of the "my favorite people" >> list. >> :) > > It's really Shane (www.lottadot.com) whom should be in your list. He's > the one coding and I'm merely annoying him with feature requests ;-) I can't take all the credit. I don't know jack about all this geostuff if it weren't for Alex. Shane -- My slashcode stuff: http://slash.lottadot.com/ Slashcode faq: http://slash.lottadot.com/slash-faq How to ask a question: http://www.catb.org/~esr/faqs/smart- questions.html#before |
From: shane <sh...@lo...> - 2006-08-29 13:44:54
|
On Aug 25, 2006, at 5:32 PM, Larson, Timothy E. wrote: > Alexandre Leroux wrote: >> You'll be happy Tim, the GeoRSS standard (it's a Open Geospatial >> Consortium standard, see http://www.opengeospatial.org/) allows not >> only points, but lines and polygons. So this means, to take your >> example, you can specify Canada or Middle-East with a polygon. >> This is > > So I'd just have to define my polygons when creating the site, and add > this list to the story submit page? Cool. No. You define the points when you submit the story. Or, you define the points when you are editing a story. See http://slashgeo.org/submit.pl For any nexus: that you want to ask for said coordinates that you want the stories to use the geo data you have to define topic Extras to contain the data. screenshot: http://images.lottadot.com/screenshots/ geotopicextraseditpage.png See http://slash.lottadot.com/article.pl?sid=05/06/15/1449258 for information about using Topic Extras to contain any type of arbitrary data w/ your stories. Shane |
From: Larson, T. E. <TEL...@we...> - 2006-08-29 14:17:46
|
shane wrote: > On Aug 25, 2006, at 4:59 PM, Larson, Timothy E. wrote: >> I'd've been happy with a even a list of regions/countries to choose >> from when submitting stories. How hard is it to reliably map any >> given coordinate pair to a city/country/state/area? I can certainly >> see the utility in finding local postings (i.e. "within 200 km of >> <coord>") but more likely (for my needs) I'd want to focus on >> "Canada" or "Manhattan" or "Middle East". It certainly would be >> easier (for non-geography buffs) to submit something like this (i.e. >> picking from a list, clicking a map region) with stories rather than >> coordinate pairs.=20 >=20 > Where would one obtain such data? It would have to be defined somewhere on the site, but that would be done by the admins during setup, and only once. If this GeoRSS thing is that big already, I imagine someone somewhere has already done some of the work: defining the boundaries of countries, states, cities, landmasses, etc. You'd just have to pick the ones that work for you, and fill in the gaps. >> So this only applies to RSS, and you won't notice anything when >> visiting the site otherwise? >=20 > No. If a story has geo-data associated with it, it'll show a map. > Example: >=20 > http://industry.slashgeo.org/article.pl?sid=3D06/07/27/1337233 >=20 > It will also add tags into the html such as >=20 > <meta name=3D"geo.position" content=3D"51.5;-0.1"> >=20 > For more info on the tags: http://www.lottadot.com/projman.pl? > op=3Dviewissue&id=3D5 Very very very cool. Especially if the map view is customizable. As I've alluded to, a non-geog site would probably want a must less detailed map. Perhaps something more icon-sized, merely to give an indicator where the story is from. Essentially, highlight the "area" the location is in, surrounded by enough context for people to know what they're looking at. >> If the story has location info, I'd want to see it in the story >> somewhere. >=20 > Where? And what? That's been the big question. That depends on the nature of the site. A "hard news" site would prefix "Dateline: New York" to the story submission, perhaps. >> I think it would be a huge value-add, and very useful, especially were >> it given the ability to use "general" location as well as "specific" >> location. >=20 > In what way? To search the stories? To filter them on an index view > (as you could filter by author, or by topic?)=20 Precisely! That was my original vision for how it would work in that low-pri request. It would be a fourth piece of data along with topic, section, and author. One would be able to filter the homepage on location just as with those three. =20 In fact, 699047 describes an enhancement to home page customization that would make use of this field. Since that request, a different enhancement has been done, but the idea of using locale is still cool. On slashdot, for example, sure it's interesting that some big business 10 timezones away is switching operations to Linux, but I'm also interested in the much less earthshaking news of an Open Software Festival sponsored by a high school club in the next county. By adding support for location, big sites can still cover local news without "spamming" the non-locals. Tim --=20 Tim Larson West Corporation, Interactive TeleServices Eschew obfuscation! |
From: shane <sh...@lo...> - 2006-08-29 15:06:41
|
On Aug 29, 2006, at 10:16 AM, Larson, Timothy E. wrote: > shane wrote: >> On Aug 25, 2006, at 4:59 PM, Larson, Timothy E. wrote: >>> I'd've been happy with a even a list of regions/countries to choose >>> from when submitting stories. How hard is it to reliably map any >>> given coordinate pair to a city/country/state/area? I can certainly >>> see the utility in finding local postings (i.e. "within 200 km of >>> <coord>") but more likely (for my needs) I'd want to focus on >>> "Canada" or "Manhattan" or "Middle East". It certainly would be >>> easier (for non-geography buffs) to submit something like this (i.e. >>> picking from a list, clicking a map region) with stories rather than >>> coordinate pairs. >> >> Where would one obtain such data? > > It would have to be defined somewhere on the site, but that would be > done by the admins during setup, and only once. If this GeoRSS > thing is > that big already, I imagine someone somewhere has already done some of > the work: defining the boundaries of countries, states, cities, > landmasses, etc. You'd just have to pick the ones that work for you, > and fill in the gaps. We may have a stop gap here - http://www.lottadot.com/projman.pl?op=view&id=15 I had started that zipcode plugin, well, a very long time ago. As far as I recall, it was functional last time I messed with it. If you can, take a look at it, specifically the schema and the data it contains. From a quick glance, it looks like it has lat/long information by zip/city/state. However, defining boundaries w/ landmasses et all, er yuk. > >>> So this only applies to RSS, and you won't notice anything when >>> visiting the site otherwise? >> >> No. If a story has geo-data associated with it, it'll show a map. >> Example: >> >> http://industry.slashgeo.org/article.pl?sid=06/07/27/1337233 >> >> It will also add tags into the html such as >> >> <meta name="geo.position" content="51.5;-0.1"> >> >> For more info on the tags: http://www.lottadot.com/projman.pl? >> op=viewissue&id=5 > > Very very very cool. Especially if the map view is customizable. The maps are drawn via a template. The template expects certain things passed to it (map api key, lat, long, points) But other then that, it will be very, very highly mod'able. > >>> If the story has location info, I'd want to see it in the story >>> somewhere. >> >> Where? And what? That's been the big question. > > That depends on the nature of the site. A "hard news" site would > prefix > "Dateline: New York" to the story submission, perhaps. > >>> I think it would be a huge value-add, and very useful, especially > were >>> it given the ability to use "general" location as well as "specific" >>> location. >> >> In what way? To search the stories? To filter them on an index view >> (as you could filter by author, or by topic?) > > Precisely! That was my original vision for how it would work in that > low-pri request. It would be a fourth piece of data along with topic, > section, and author. One would be able to filter the homepage on > location just as with those three. > > In fact, 699047 describes an enhancement to home page customization > that > would make use of this field. Since that request, a different > enhancement has been done, but the idea of using locale is still cool. > On slashdot, for example, sure it's interesting that some big business > 10 timezones away is switching operations to Linux, but I'm also > interested in the much less earthshaking news of an Open Software > Festival sponsored by a high school club in the next county. By > adding > support for location, big sites can still cover local news without > "spamming" the non-locals. How would this be any different from having a topic-nexus defined that would hold all stories associated with a certain area? Then all a user has to do is hit the URL for skin to obtain that content. I bring that solution up, because that doesn't entail modifying any source code, nor schema. So far, to get the functionality that's mentioned on the project homepage ( http://lottadot.com/projects/ slashmaps ) I've not had to modify all that much source code to get these things to work. Mostly we're using topic_nexus_extras to store the information, and modified templates to show it. (I did have to complete the skins editor, and the skins_params, but that's another topic). Inorder for one to be able to essentially search by story.location (let's assume that's what it's called) efficiently, at first thought I would think we'd have to modify the stories table schema, add that column, and then modify all the story code (getStoriesEssentials,etc) in Slash.pm as well as retool a bit of Slash::Search. Then add a bit to the edituser page that would let them set the 'region/place' limiting options (just like they can exclude authors, topics). At first glance, that seems like quite a bit of work. Maybe there'd be a better way to do it. Any thoughts? I'm all ears. Another question I would have, is if you're wanting to associate a story with a location, how do you let a user exclude? by proximity to that location? how do you define proximity? lat/long? within XX miles? but that's US, so you'd want to investigate using an alternative metric. Shane -- My slashcode stuff: http://slash.lottadot.com/ Slashcode faq: http://slash.lottadot.com/slash-faq How to ask a question: http://www.catb.org/~esr/faqs/smart- questions.html#before |
From: Alexandre L. <ale...@ec...> - 2006-08-29 15:37:17
|
Hi, Larson, Timothy E. wrote: > It would have to be defined somewhere on the site, but that would be > done by the admins during setup, and only once. If this GeoRSS thing i= s > that big already, I imagine someone somewhere has already done some of > the work: defining the boundaries of countries, states, cities, > landmasses, etc. You'd just have to pick the ones that work for you, > and fill in the gaps. It's getting complex here since there are numerous possibilities. This=20 could be done directly using "RSS to GeoRSS Converter" from Geonames.org: http://www.geonames.org/rss-to-georss-converter.html However, I still feel a custom-made list of locations that can be=20 ordered as wished would still be more useful/convenient. As for zip code geocoding, I don't know much myself about this, but I=20 know it's pretty easy. See http://technology.slashgeo.org/article.pl?sid=3D06/01/21/054201 and http://technology.slashgeo.org/article.pl?sid=3D06/06/15/1312224 >> In what way? To search the stories? To filter them on an index view >> (as you could filter by author, or by topic?)=20 >=20 > Precisely! That was my original vision for how it would work in that > low-pri request. It would be a fourth piece of data along with topic, > section, and author. One would be able to filter the homepage on > location just as with those three. =20 Humm.. this raises an important issue. Do you want slash to manage the=20 'spatial queries' or let the user's GeoRSS reader do the job? I tend to=20 opt for the GeoRSS reader, since those will evolve/improve way faster=20 than slash does. The Slash engine could allow basic searches on archives=20 using a bounding box. Logically, a GeoRSS feed shows only geolocated stories. Slashdot has=20 only 10 RSS items in its list, this means the slashdot map of georss=20 stories will be most of the time empty. This is bad. However, I guess=20 it's possible to map on the slashsite more than only the published RSS=20 items (see Shane's work-in-progress http://slashgeo.org/maps.pl ).=20 Probably showing the last 25 geolocated stories would make sense. The=20 exact number could be a var. Alex --=20 Alexandre Leroux, M.Sc., Ing. Environnement Canada / Environment Canada Centre m=E9t=E9orologique canadien / Canadian Meteorological Centre Division de la r=E9ponse aux urgences environnementales / Environmental Emergency Response Division ale...@ec... |
From: Larson, T. E. <TEL...@we...> - 2006-08-29 15:32:56
|
shane wrote: > On Aug 29, 2006, at 10:16 AM, Larson, Timothy E. wrote: > http://www.lottadot.com/projman.pl?op=3Dview&id=3D15 >=20 > I had started that zipcode plugin, well, a very long time ago. As far > as I recall, it was functional last time I messed with it. If you can, > take a look at it, specifically the schema and the data it contains. > From a quick glance, it looks like it has lat/long information by > zip/city/state. =20 >=20 > However, defining boundaries w/ landmasses et all, er yuk. Don't have time to look right now, but it sounds like it's a step in the right direction. >> Precisely! That was my original vision for how it would work in that >> low-pri request. It would be a fourth piece of data along with topic, >> section, and author. One would be able to filter the homepage on >> location just as with those three. >>=20 >> In fact, 699047 describes an enhancement to home page customization >> that would make use of this field. Since that request, a different >> enhancement has been done, but the idea of using locale is still cool. >> On slashdot, for example, sure it's interesting that some big business >> 10 timezones away is switching operations to Linux, but I'm also >> interested in the much less earthshaking news of an Open Software >> Festival sponsored by a high school club in the next county. By >> adding support for location, big sites can still cover local news >> without "spamming" the non-locals. >=20 > How would this be any different from having a topic-nexus defined that > would hold all stories associated with a certain area?=20 It probably wouldn't be...just a different implementation of the idea. Slash topics have become much more...tag-like I suppose. Having separate fields reinforces the notion that they are different types of data, but from the user perspective of "being able to focus in interesting stuff" it doesn't really matter much. If you can intersect two sets of information to get the interesting subset, that's the important thing. > I bring that solution up, because that doesn't entail modifying any > source code, nor schema. So far, to get the functionality that's > mentioned on the project homepage ( http://lottadot.com/projects/ > slashmaps ) I've not had to modify all that much source code to get > these things to work. Mostly we're using topic_nexus_extras to store > the information, and modified templates to show it. (I did have to > complete the skins editor, and the skins_params, but that's another > topic). =20 >=20 > Inorder for one to be able to essentially search by story.location > (let's assume that's what it's called) efficiently, at first thought I > would think we'd have to modify the stories table schema, add that > column, and then modify all the story code (getStoriesEssentials,etc) > in Slash.pm as well as retool a bit of Slash::Search. Then add a bit > to the edituser page that would let them set the 'region/place' =20 > limiting options (just like they can exclude authors, topics). >=20 > At first glance, that seems like quite a bit of work. Maybe there'd be > a better way to do it. Any thoughts? I'm all ears.=20 Nope, that's pretty much what I thought I'd have to do someday, when I submitted the request. Reworking of topics to allow for multiples and the behavior we have now essentially allows the same thing, and more easily. > Another question I would have, is if you're wanting to associate a > story with a location, how do you let a user exclude? by proximity to > that location? how do you define proximity? lat/long? within XX miles? > but that's US, so you'd want to investigate using an alternative > metric. =20 This is where treating geo information specially would be helpful. If the lat/long input simply gets mapped to a topic (which you can filter on, of course) you lose granularity/flexibility. You could do both, of course. Using a topic nexus would be quick and easy, and give rough idea of location. For most sites I imagine that would be sufficient. Adding support for <proximity> to <location> as well would be a refinement down the road. Flagging things in my immediate vicinity for homepage display (that I otherwise might not care about) would be cool. Tim --=20 Tim Larson West Corporation, Interactive TeleServices Eschew obfuscation! |
From: Larson, T. E. <TEL...@we...> - 2006-08-29 15:44:22
|
Alexandre Leroux wrote: > It's getting complex here since there are numerous possibilities. This > could be done directly using "RSS to GeoRSS Converter" from > Geonames.org: http://www.geonames.org/rss-to-georss-converter.html=20 > However, I still feel a custom-made list of locations that can be > ordered as wished would still be more useful/convenient.=20 I agree. I always envisioned a set list of locations, as determined by the site admin. A US-focused site may have each state as an item, as well as "Europe", "Asia", etc. > Humm.. this raises an important issue. Do you want slash to manage the > 'spatial queries' or let the user's GeoRSS reader do the job? I tend to > opt for the GeoRSS reader, since those will evolve/improve way faster > than slash does. The Slash engine could allow basic searches on > archives=20 > using a bounding box. I'm still a very newbie user to RSS altogether. I think the site itself needs to have some basic capabilities. Tim --=20 Tim Larson West Corporation, Interactive TeleServices Eschew obfuscation! |
From: Eric D. <eri...@ja...> - 2006-08-25 21:03:20
|
I still think a great plugin/feature would be to allow approved users to be able to submit files/pictures in replies to articles. Larson, Timothy E. wrote: > Alexandre Leroux wrote: > >> The first feature is adding GeoRSS tags to the RSS feed of the slash >> site. You can learn more about on http://georss.org and >> http://slashgeo.org/search.pl?query=georss. In short, RSS items are >> geolocated, meaning they can be mapped or queried by the user. >> Example: >> show me RSS story items that are within 50 miles of my state. My goal >> was simply to have an automated map my slash stories. It works :-) (I >> can't show you a map of slashgeo.org's mapped georss feed since I >> stopped geocoding stories until feature #2 below stops showing errors >> for geolocated stories :-) >> > [snip] > >> My slash site, slashgeo.org, will definitely use the plugin and >> geolocate every story whenever appropriate. Ultimately, people will be >> able to browse stories by location, say, stories that relates to the >> UK. >> > > Hmmm... > > Slash - Low-Priority Feature Requests, 699051, story regionalization > > I'd've been happy with a even a list of regions/countries to choose from > when submitting stories. How hard is it to reliably map any given > coordinate pair to a city/country/state/area? I can certainly see the > utility in finding local postings (i.e. "within 200 km of <coord>") but > more likely (for my needs) I'd want to focus on "Canada" or "Manhattan" > or "Middle East". It certainly would be easier (for non-geography > buffs) to submit something like this (i.e. picking from a list, clicking > a map region) with stories rather than coordinate pairs. > > So this only applies to RSS, and you won't notice anything when visiting > the site otherwise? If the story has location info, I'd want to see it > in the story somewhere. > > >> What's the overhead? Not much. You simply need to specify a location >> (latitude / longitude coordinates) for your stories. Does it generate >> added-value? Well, to my readers, yes, since we're geospatial >> professionals. To your slashsite? You're the judge! :-) >> > > I think it would be a huge value-add, and very useful, especially were > it given the ability to use "general" location as well as "specific" > location. But like I alluded to, I don't know how difficult it would be > to piggyback the general on top of the specific. > > Tim > |
From: shane <sh...@lo...> - 2006-08-29 13:35:13
|
On Aug 25, 2006, at 5:03 PM, Eric Dannewitz wrote: > I still think a great plugin/feature would be to allow approved > users to > be able to submit files/pictures in replies to articles. Would what they submitted be attached to the story, or their comment? It would be trivial to show an image (that the user picked) with each user's comment. Just add an entry for them in the editUser template (a text input) and then alter the displayComment templates to include that user.myimagelink in the html. Is this safe and adviseable? Lots of sites do this (ie UBB, etc) I wouldn't on any sites I run. But that's just me. I think it depends on the website, personally. Shane |
From: Eric D. <eri...@ja...> - 2006-08-29 18:31:49
|
I was thinking more like users with an elevated access level (like approved users) would be able to participate in stories that we could attach PDFs or JPGs to. I was thinking more along the lines of using BLOBs.......... shane wrote: > On Aug 25, 2006, at 5:03 PM, Eric Dannewitz wrote: > > >> I still think a great plugin/feature would be to allow approved >> users to >> be able to submit files/pictures in replies to articles. >> > > Would what they submitted be attached to the story, or their comment? > > It would be trivial to show an image (that the user picked) with each > user's comment. Just add an entry for them in the editUser template > (a text input) and then alter the displayComment templates to include > that user.myimagelink in the html. > > Is this safe and adviseable? Lots of sites do this (ie UBB, etc) I > wouldn't on any sites I run. But that's just me. I think it depends > on the website, personally. > > Shane > |
From: Alexandre L. <ale...@ec...> - 2006-08-25 21:24:39
|
Hi, >more likely (for my needs) I'd want to focus on "Canada" or "Manhattan" >or "Middle East". It certainly would be easier (for non-geography >buffs) to submit something like this (i.e. picking from a list, clickin= g >a map region) with stories rather than coordinate pairs. You'll be happy Tim, the GeoRSS standard (it's a Open Geospatial=20 Consortium standard, see http://www.opengeospatial.org/) allows not only=20 points, but lines and polygons. So this means, to take your example, you=20 can specify Canada or Middle-East with a polygon. This is -already- in=20 the plugin :-) One of the improvements will be to allow adding and=20 selecting regularly used 'locations' from a list, instead of having to=20 type the whole coordinates in the story edition page. This droplist=20 could be provided to users submitting stories. I wasn't aware there was previous feature request of story=20 'regionalization'. If you ask me, GeoRSS is the way to go, since it is a=20 standard. > So this only applies to RSS, and you won't notice anything when visitin= g > the site otherwise? If the story has location info, I'd want to see it > in the story somewhere. That's where the Google Maps API part comes into play. (have you read=20 the comments in the IssueList link I provided? ;-) Idealy, you will be=20 able to map your GeoRSS directly on a map on your slash site. Right now,=20 it works when using other sites such as Mapufacture.com to automatically=20 map my slash stories, but having this maps directly on the slash site=20 would be nice. This is only the beginning (but since my own developer=20 skills aren't too high and there aren't that many people developing=20 slash, who knows at what pace this plugin will evolve...). As I wrote,=20 you can also add maps for individual stories whenever appropriate. > I think it would be a huge value-add, and very useful, especially were I'm happy to hear this :-) Have a great weekend! Alex --=20 Alexandre Leroux, M.Sc., Ing. Environnement Canada / Environment Canada Centre m=E9t=E9orologique canadien / Canadian Meteorological Centre Division de la r=E9ponse aux urgences environnementales / Environmental Emergency Response Division ale...@ec... |
From: shane <sh...@lo...> - 2006-08-29 13:37:34
|
On Aug 25, 2006, at 5:24 PM, Alexandre Leroux wrote: > > Hi, > >> more likely (for my needs) I'd want to focus on "Canada" or >> "Manhattan" >> or "Middle East". It certainly would be easier (for non-geography >> buffs) to submit something like this (i.e. picking from a list, >> clicking >> a map region) with stories rather than coordinate pairs. > > You'll be happy Tim, the GeoRSS standard (it's a Open Geospatial > Consortium standard, see http://www.opengeospatial.org/) allows not > only > points, but lines and polygons. So this means, to take your > example, you > can specify Canada or Middle-East with a polygon. This is -already- in > the plugin :-) Well, the container to hold that data w/ the story (or submission) is there. The code to render that polygon/lines within the google map isn't there. It'll come with finding freetime :) > One of the improvements will be to allow adding and > selecting regularly used 'locations' from a list, instead of having to > type the whole coordinates in the story edition page. This droplist > could be provided to users submitting stories. I'd been thinking on this one quite a bit. I envisioned a drop down that onchange would fill in the geopoints data from whatever was selected on the dropdown. > > I wasn't aware there was previous feature request of story > 'regionalization'. Me neither. Shane |
From: Alexandre L. <ale...@ec...> - 2006-08-29 15:09:03
|
shane wrote: > Well, the container to hold that data w/ the story (or submission) is =20 > there. The code to render that polygon/lines within the google map =20 > isn't there. It'll come with finding freetime :) Don't look too hard for freetime for this ;-) Most GeoRSS readers=20 (web-based or not) only read/allow point coordinates so far. Until=20 GeoRSS is widely used and lines/polygons are supported on both sides=20 (thus including the reader), focusing on points is the logical thing to=20 do. This is true for the GeoRSS part of the plugin. For the Mashup part of the plugin, publishing lines and polygons would=20 be nice, but if you ask me, this isn't a priority!! I don't think we=20 want a full-fledge map server, this is slash, a weblog system!=20 Lines/Polygons/Box could be disabled to keep only points and this would=20 still be great :-) Alex :-) --=20 Alexandre Leroux, M.Sc., Ing. Environnement Canada / Environment Canada Centre m=E9t=E9orologique canadien / Canadian Meteorological Centre Division de la r=E9ponse aux urgences environnementales / Environmental Emergency Response Division ale...@ec... |
From: shane <sh...@lo...> - 2006-08-29 13:33:34
|
On Aug 25, 2006, at 4:59 PM, Larson, Timothy E. wrote: > Alexandre Leroux wrote: >> The first feature is adding GeoRSS tags to the RSS feed of the slash >> site. You can learn more about on http://georss.org and >> http://slashgeo.org/search.pl?query=georss. In short, RSS items are >> geolocated, meaning they can be mapped or queried by the user. >> Example: >> show me RSS story items that are within 50 miles of my state. My goal >> was simply to have an automated map my slash stories. It works :-) (I >> can't show you a map of slashgeo.org's mapped georss feed since I >> stopped geocoding stories until feature #2 below stops showing errors >> for geolocated stories :-) > [snip] >> My slash site, slashgeo.org, will definitely use the plugin and >> geolocate every story whenever appropriate. Ultimately, people >> will be >> able to browse stories by location, say, stories that relates to the >> UK. > > Hmmm... > > Slash - Low-Priority Feature Requests, 699051, story regionalization > > I'd've been happy with a even a list of regions/countries to choose > from > when submitting stories. How hard is it to reliably map any given > coordinate pair to a city/country/state/area? I can certainly see the > utility in finding local postings (i.e. "within 200 km of <coord>") > but > more likely (for my needs) I'd want to focus on "Canada" or > "Manhattan" > or "Middle East". It certainly would be easier (for non-geography > buffs) to submit something like this (i.e. picking from a list, > clicking > a map region) with stories rather than coordinate pairs. Where would one obtain such data? > > So this only applies to RSS, and you won't notice anything when > visiting > the site otherwise? No. If a story has geo-data associated with it, it'll show a map. Example: http://industry.slashgeo.org/article.pl?sid=06/07/27/1337233 It will also add tags into the html such as <meta name="geo.position" content="51.5;-0.1"> For more info on the tags: http://www.lottadot.com/projman.pl? op=viewissue&id=5 > If the story has location info, I'd want to see it > in the story somewhere. Where? And what? That's been the big question. > >> What's the overhead? Not much. You simply need to specify a location >> (latitude / longitude coordinates) for your stories. Does it generate >> added-value? Well, to my readers, yes, since we're geospatial >> professionals. To your slashsite? You're the judge! :-) > > I think it would be a huge value-add, and very useful, especially were > it given the ability to use "general" location as well as "specific" > location. In what way? To search the stories? To filter them on an index view (as you could filter by author, or by topic?) Shane |
From: shane <sh...@lo...> - 2006-08-29 19:07:01
|
Ya know what would be cool? Being able to embed Template toolkit logic within a story text. ie start new story add content, save it, don't queue to show. edit it later, upload file(s) into said story. then when you edit the story blah blah content content... [% IF !user.is_anon %] Attached files: <ul> <li><slash-tag></li> <li><slash-tagforfile#2></li> </ul> [% END %] then you could have story content show only for logged in users, or only for subscribers, etc etc. Shane On Aug 29, 2006, at 2:32 PM, Eric Dannewitz wrote: > I was thinking more like users with an elevated access level (like > approved users) would be able to participate in stories that we could > attach PDFs or JPGs to. I was thinking more along the lines of using > BLOBs.......... > > shane wrote: >> On Aug 25, 2006, at 5:03 PM, Eric Dannewitz wrote: >> >> >>> I still think a great plugin/feature would be to allow approved >>> users to >>> be able to submit files/pictures in replies to articles. >>> >> >> Would what they submitted be attached to the story, or their comment? >> >> It would be trivial to show an image (that the user picked) with each >> user's comment. Just add an entry for them in the editUser template >> (a text input) and then alter the displayComment templates to include >> that user.myimagelink in the html. >> >> Is this safe and adviseable? Lots of sites do this (ie UBB, etc) I >> wouldn't on any sites I run. But that's just me. I think it depends >> on the website, personally. >> >> Shane >> > > > ---------------------------------------------------------------------- > --- > Using Tomcat but need to do more? Need to support web services, > security? > Get stuff done quickly with pre-integrated technology to make your > job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache > Geronimo > http://sel.as-us.falkag.net/sel? > cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Slashcode-general mailing list > Sla...@li... > https://lists.sourceforge.net/lists/listinfo/slashcode-general |
From: Clifton W. <cli...@gm...> - 2006-08-29 23:34:21
|
Would be neat, but could also be BAAAD JUJU. Because effectively, there would need to be some kind of security model in place for Templates in stories otherwise the potential for site pwnage would be very high. - Cliff PS. If you wanted to do something like that, you could with a 2-phased template process approach. Instead of using the standard tags, you could use custom story tags of your own, ala: blah blah content content... <!+ IF !user.is_anon !+> Attached files: <ul> <li><slash-tag></li> <li><slash-tagforfile#2></li> </ul> <!+ END !+> Where "<!+" and "!+>" are my lame attempts at custom tags. The reason for the 2-phased approach would solely be ease of implementation. Trying to do it in one phase right now would give me a massive coronary (considering my current migraine). So the end of dispStory() should read something like this: sub dispStory { ... if ($constants->{templates_in_stories}) { my($story, $body) = ($story->{introtext}, $story->{bodytext}; my($tag) = '[% TAGS "<!+" "!+>" %]'; $story = "$tag\n$story"; $body = "$tag\n$body"; slashDisplay($story, {}, \$story); slashDisplay($body, {}, \$body); $story->{introtext} = $story; $story->{bodytext} = $body; } return slashDisplay($template_name, \%data, 1); } Or something like that. It's be a while so I might be missing the syntax of a rew things, but that's one way how it could be done. Note that this does not account for several pieces of the engine that I haven't had a chance to familiarize myself with... most notably story pre-rendering. This is only a hint as to how it could be done. I'm sure many of you could do it better. But for God's Sake, please read the non-postcript portion of this message again before attempting to implement something like this ];-} - Cliff On 8/29/06, shane <sh...@lo...> wrote: > > Ya know what would be cool? Being able to embed Template toolkit > logic within a story text. ie > > start new story > add content, save it, don't queue to show. > edit it later, upload file(s) into said story. > then when you edit the story > > blah blah content content... > [% IF !user.is_anon %] > Attached files: > <ul> > <li><slash-tag></li> > <li><slash-tagforfile#2></li> > </ul> > [% END %] > > then you could have story content show only for logged in users, or > only for subscribers, etc etc. > > Shane > |
From: shane <sh...@lo...> - 2006-09-14 22:59:06
|
On Aug 29, 2006, at 7:34 PM, Clifton Wood wrote: > Would be neat, but could also be BAAAD JUJU. Because effectively, > there would need to be some kind of security model in place for > Templates in stories otherwise the potential for site pwnage would > be very high. > > - Cliff Can you elaborate on this a little bit? I don't see where the problem would lie. My thinking is that it's different from a .tmpl file. The one obstacle I could see is the pre-rendering of the stories. Slashd writes them to disk as .shtml's, so there'd be no question, it'd just ignore the template toolkit code within the story.introtext and bodytext. But when a user hits articles.pl does it show pre-rendered (from cache) or render it right then and there? If right then and there, it would seem the template running would be no different from a .tmpl and it'd be limited to the current user. Obviously, you'd have to fully trust your site admins (ie authors) with writing template toolkit code. That in itself is kinda scary. Shane |
From: Clifton W. <cli...@gm...> - 2006-09-16 22:43:40
|
On 9/14/06, shane <sh...@lo...> wrote: > > > Can you elaborate on this a little bit? I don't see where the problem > would lie. My thinking is that it's different from a .tmpl file. Basically, once you can write template code, the potential for being able to co-opt a site is very, very high. Template code == Database access with the right plugin. I don't think Slash tries to prevent against that. Plus, it's very easy for a template to perform one query too many and drive down site performance. If this is done for -every story view-, you might be a long time in finding the problem. Of course, I'm being paranoid and extremist in my examples, but rather prepare you for the worst rather than hand you a pair of rose-colored glasses and have everything fall apart. The one obstacle I could see is the pre-rendering of the stories. > Slashd writes them to disk as .shtml's, so there'd be no question, > it'd just ignore the template toolkit code within the story.introtext > and bodytext. For .shtmls, yes. This might be true, however that's ONLY if you are planning on using templates-in-stories for anonymous vs logged in content. If you have bigger things in mind, even .shtml generation might bring up some issues. > But when a user hits articles.pl does it show pre-rendered (from > cache) or render it right then and there? If right then and there, it > would seem the template running would be no different from a .tmpl > and it'd be limited to the current user. I'm not quite up-to-speed on the entire pre-rendering mechanism, but I *think* the pre-rendered form is shown in normal site operation for logged in users. This might cause problems for non-saavy users who are expecting more dynamic content from the implication of templates-in-stories. > Obviously, you'd have to fully trust your site admins (ie authors) > with writing template toolkit code. That in itself is kinda scary. And that's pretty much what I was referring to. Remember, if you include the ability to write templates in stories, a bad apple need only break into the *site* to potentially damage the entire server. For someone to abuse .tmpl files, they'd have to break into the *server*, which while also doable is a bit more difficult. It basically all boils down to a matter of trust. And having admins write (potentially bad) template code can make debugging site problems two to three times as hard. Even innocent stuff like missing "-%>" can cause really wacky things to happen and it's not like the site admin can browse the error logs to find out the problem. All in all, I see less gains than issues with doing such things without a lot of learning curve, proper training, and huge amounts of trust before something would be gained by such a thing. Not saying it might not be a worthwhile addition to a sight run by a tight core group of editors (which is why I included a way it *might* work in my original missive), but that it might not be something that only the saaviest of Slashcode site admins need consider. - Cliff |