Re: [OSGeo-Discuss] OSCAR project status
Hi We're still around and have been working on OSCAR. At this stage we are working on the process aspects of the approach. We are working towards opening it up but that is still some time away. A project page is currently being set up and I'll post details here as soon as that's up. Thanks for the continued interest in this and we will keep you informed. regards Geoff From: discuss-boun...@lists.osgeo.org [discuss-boun...@lists.osgeo.org] on behalf of Allan Oware [lumte...@gmail.com] Sent: Wednesday, 1 August 2012 6:41 p.m. To: discuss@lists.osgeo.org Subject: [OSGeo-Discuss] OSCAR project status Hi all, I've come across texts mentioning the Open Source Cadastral and Registry application and was wondering whether the project is still in active development. Does anyone have links to the application itself or code since the project wikihttp://source.otago.ac.nz/oscar/OSCAR_Home only provides theoretical information and presentations ? Thanks -- Allan Oware Upande LTD | www.upande.comhttp://www.upande.com ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
RE: [OSGeo-Discuss] multi-lingual WMS-legends
Hi In my project I am using Web Ontology Language (OWL W3C.org) to sort out multi lingual labels (among other things). I have found it works extremely well and allows this specific stuff to be managed separately from any of the aps that might require this. I manage the actual labels with Protege. Geoff From: discuss-boun...@lists.osgeo.org [discuss-boun...@lists.osgeo.org] on behalf of Adrian Custer [acus...@gmail.com] Sent: Wednesday, 25 May 2011 11:03 a.m. To: discuss@lists.osgeo.org Subject: Re: [OSGeo-Discuss] multi-lingual WMS-legends Hey Cameron, all, On 05/25/2011 12:12 AM, Cameron Shorter wrote: OGC standards people, Have there been any discussions at the OGC level about specifying language support within OGC standards? Yes, we have had discussions; no we have not yet found solutions. As part of our work cleaning up the WMS mess for 2.0, I have looked at the language rules given by 'OWS Common' (the proposed base layer for all OGC Web Services). Those rules seem both restrictive and broken (due to mutually incompatible requirements). The broken can be fixed, however the fundamental approach itself is problematic for WMS. The approach of OWS Common forces any OGC web service that wishes to advertise that it supports a particular language to offer *all* its text strings in all of its resources in that language. The bar is therefore exceedingly high---it seems to argue that if any layer of labels on the service cannot be obtained with all its labels in a particular language, that language cannot be said to be supported by the service. For WMS labels of, say, place names, this all or nothing approach seems needlessly restrictive; it is hard enough to get labels of any kind for a country or continent without trying to get them all in a single language (let alone several). I suspect the current approach sets an impossibly high requirement. Regardless, it seems like it would be useful to have some language mechanism, presumably using an additional but complimentary approach, based on a best effort contract. (Note that INSPIRE too seems to use the 'everything must be fully translated' approach, if I remember correctly.) Then there are a few technical difficulties that will need to be resolved---e.g. OWS Common requires that each and every string which is localized to have its localization labelled directly on the XML element without explaining if/how this labelling should work on non XML elements. Also, there are many strings which should *not* be localized so it would be better if the various OWS services identified which fields were expected to contain human readable, textual content. There is also the problem that INSPIRE seems to be using its own particular language identifiers different from those commonly found in the world of the Web. There are other issues as well that are not coming to mind right now but will need to be addressed. So it seems there are two needs for language support: one in which Servers indicate they have full and complete support for a particular language, another through which they may indicate a best effort support for a given language. As to the details of the mechanisms of how a client indicates its particular language preference and how a server indicates the particular languages in which it has offerings, they are part of our ongoing work cleaning up the 'what a mess' of WMS. Easy, pragmatic solutions which solve anyone's particular needs can readily be found (and the 'lang=' parameter seems to be one such solution); solving the general need for all OGC Services needs someone to wade through the problem space, discover alternative solutions, evaluate those alternative solutions, develop a mechanism to enable the best of these solutions, and finally develop the injunctions which will make it work. For our work on WMS 2.0, we have accumulated notes on the language issues but not yet progressed to develop alternative possible solutions nor decided on how to implement the best of those solutions. We did decide that our contribution to fixing OWS Common would come after we had done the bulk of the work on WMS 2.0. ~adrian ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
[OSGeo-Discuss] RE: Representing Places With Intelligent URLs
Hi The knowledge you are trying to encode should be represented as associations between individuals (this place contains that place etc) and concepts (city, park, post office delivery area, etc) (as in OWL) rather than a URI scheme (see Geonames). The basic idea is to represent places in a way that allows inference (make implicit knowledge explicit) i.e. logical consequence e.g. Explicit: a country only has only one capital city Explicit: NZ is a country Explicit: Wellington is the capital of NZ Explicit: 'Te Upoko o te Ika a Maui' is the capital of NZ Implicit: Wellington and 'Te Upoko o te Ika a Maui' are the same place - you cant do this nicely with a URL scheme but an OWL reasoner can make such conclusions - yehar Semantic Web. Actualy there is really no problem with your URI scheme otherwise. It looks exactly like what you would expect for REST Web Services URLs - as long as you don't expect your URLs to be the ultimate and final identifiers - that would break both of the two main assumptions behind the semantic web and its underlying formal logics. regards Geoff From: discuss-boun...@lists.osgeo.org [discuss-boun...@lists.osgeo.org] On Behalf Of Landon Blake [lbl...@ksninc.com] Sent: Wednesday, 6 October 2010 12:45 p.m. To: OSGeo Discussions Subject: [OSGeo-Discuss] Representing Places With Intelligent URLs A talk at the recent Location Business Summit and some reading I've done about the semantic web and microformats lately got me to thinking about a standard way to represent places, place names, place data on the web. (I must admit I'm a desktop software guy, not a web programmer.) I thought it would be awesome if there was a way to create a unique URL for places that was somewhat intelligent to humans. If this URL could point to a folder on a server with some basic information about a place, that would be even better. So I took a stab at creating this type of URL for my city, the City of Stockton. Here it is: http://www.standardwebmarkup.org/standard_places/north_america/united_st ates_of_america/california/san_joaquin_county/city_of_stockton/ You can see the URL follows a logical hierarchy, and it would be easy to determine what the URL for the City of Sacramento, San Joaquin County, or Victory Park in the City of Stockton would be. Obviously the continent/country/state/county/city/location URL pattern would have to change for other parts of the world. I put a very simple HTML file with data about the City of Stockton here: http://www.standardwebmarkup.org/standard_places/north_america/united_st ates_of_america/california/san_joaquin_county/city_of_stockton/info.html The current info.html file is just a skeleton. It's more of a place holder right now than anything else. My thought was to also put a WKT file (place.wkt) representing the location of the place and a simple text file (data.txt) with facts about the place at this same URL: http://www.standardwebmarkup.org/standard_places/north_america/united_st ates_of_america/california/san_joaquin_county/city_of_stockton/ Now, if someone wanted to write content about the City of Stockton, they could simply do something like this: a href=http://www.standardwebmarkup.org/standard_places/north_america/uni ted_states_of_america/california/san_joaquin_county/city_of_stockton/S tockton/a If everyone that was putting web content about Stockton online did the same thing, search engine and other tools would be able to link data from this web content to a single location. This becomes even more powerful if we come up with some rules for the content of the info.html file, place.wkt file, and the data text file. Here are some examples: (1) Specify that the place.wkt file have both a point and a polygon WKT representation, or a linestring representation, of the place when appropriate. (2) Specify that the info.html file use a list with alternate place names. This list would be identified with an html class value of alternate_place_names. (3) Specify that the data.txt file contain a relationships section that can contain an optional relationship in the form of: City is the County Seat of County. (Stockton is the County Seat of San Joaquin County.) (4) Standardize the way common place facts are stored in the data.txt file. Population and area are examples. I realize there are some problems with this overall scheme. How do you store a city that straddles a state boundary, for example? Or what if you want to have a URL for the location of the Pacific Garbage Patch? However, I think we could use this system to uniquely identify and describe a lot of places in the world. We could then work on how to handle the edge cases. Is anyone else interested in ironing out the kinks for a system like this? Is there already a system like this in place? (If so, I have just revealed my great ignorance to everyone on this mailing list.) I'm interested in setting something up that could be maintained
RE: [OSGeo-Discuss] RE: Representing Places With Intelligent URLs
Hi Yes it's a blatent simplification, although... semantics... Interesting the association between truth and space, and then there's time regards Geoff From: discuss-boun...@lists.osgeo.org [discuss-boun...@lists.osgeo.org] On Behalf Of P Kishor [punk.k...@gmail.com] Sent: Thursday, 7 October 2010 10:14 a.m. To: OSGeo Discussions Subject: Re: [OSGeo-Discuss] RE: Representing Places With Intelligent URLs On Wed, Oct 6, 2010 at 3:45 PM, Geoff Hay geoffrey@otago.ac.nz wrote: Hi The knowledge you are trying to encode should be represented as associations between individuals (this place contains that place etc) and concepts (city, park, post office delivery area, etc) (as in OWL) rather than a URI scheme (see Geonames). The basic idea is to represent places in a way that allows inference (make implicit knowledge explicit) i.e. logical consequence e.g. Explicit: a country only has only one capital city I am assuming the above is just for illustration, because we have http://en.wikipedia.org/wiki/List_of_countries_with_multiple_capitals To make matters worse, we also have http://en.wikipedia.org/wiki/List_of_countries_spanning_more_than_one_continent and http://en.wikipedia.org/wiki/List_of_metropolitan_areas_that_overlap_multiple_countries and probably more. Explicit: NZ is a country Explicit: Wellington is the capital of NZ Explicit: 'Te Upoko o te Ika a Maui' is the capital of NZ Implicit: Wellington and 'Te Upoko o te Ika a Maui' are the same place - you cant do this nicely with a URL scheme but an OWL reasoner can make such conclusions - yehar Semantic Web. Actualy there is really no problem with your URI scheme otherwise. It looks exactly like what you would expect for REST Web Services URLs - as long as you don't expect your URLs to be the ultimate and final identifiers - that would break both of the two main assumptions behind the semantic web and its underlying formal logics. regards Geoff From: discuss-boun...@lists.osgeo.org [discuss-boun...@lists.osgeo.org] On Behalf Of Landon Blake [lbl...@ksninc.com] Sent: Wednesday, 6 October 2010 12:45 p.m. To: OSGeo Discussions Subject: [OSGeo-Discuss] Representing Places With Intelligent URLs A talk at the recent Location Business Summit and some reading I've done about the semantic web and microformats lately got me to thinking about a standard way to represent places, place names, place data on the web. (I must admit I'm a desktop software guy, not a web programmer.) I thought it would be awesome if there was a way to create a unique URL for places that was somewhat intelligent to humans. If this URL could point to a folder on a server with some basic information about a place, that would be even better. So I took a stab at creating this type of URL for my city, the City of Stockton. Here it is: http://www.standardwebmarkup.org/standard_places/north_america/united_st ates_of_america/california/san_joaquin_county/city_of_stockton/ You can see the URL follows a logical hierarchy, and it would be easy to determine what the URL for the City of Sacramento, San Joaquin County, or Victory Park in the City of Stockton would be. Obviously the continent/country/state/county/city/location URL pattern would have to change for other parts of the world. I put a very simple HTML file with data about the City of Stockton here: http://www.standardwebmarkup.org/standard_places/north_america/united_st ates_of_america/california/san_joaquin_county/city_of_stockton/info.html The current info.html file is just a skeleton. It's more of a place holder right now than anything else. My thought was to also put a WKT file (place.wkt) representing the location of the place and a simple text file (data.txt) with facts about the place at this same URL: http://www.standardwebmarkup.org/standard_places/north_america/united_st ates_of_america/california/san_joaquin_county/city_of_stockton/ Now, if someone wanted to write content about the City of Stockton, they could simply do something like this: a href=http://www.standardwebmarkup.org/standard_places/north_america/uni ted_states_of_america/california/san_joaquin_county/city_of_stockton/S tockton/a If everyone that was putting web content about Stockton online did the same thing, search engine and other tools would be able to link data from this web content to a single location. This becomes even more powerful if we come up with some rules for the content of the info.html file, place.wkt file, and the data text file. Here are some examples: (1) Specify that the place.wkt file have both a point and a polygon WKT representation, or a linestring representation, of the place when appropriate. (2) Specify that the info.html file use a list with alternate place names. This list would be identified with an html class value
RE: [OSGeo-Discuss] Thoughts on how to use elevation in routing
Hi All I seem to remember reading somewhere that UPS delivery routes are constructed with only right turns (or left depending on the country) so as to make use of 'free' turns to avoid waiting at traffic lights. Geoff From: discuss-boun...@lists.osgeo.org [discuss-boun...@lists.osgeo.org] On Behalf Of Bob Basques [bob.basq...@ci.stpaul.mn.us] Sent: Wednesday, 15 September 2010 6:26 a.m. To: discuss@lists.osgeo.org Cc: Stephen Carver; Justin Washtell Subject: RE: [OSGeo-Discuss] Thoughts on how to use elevation in routing All, The view of road, got me thinking about auto-placement of bridges and their locations, and even what road is above what other road. While not being able to tell exactly how long a bridge might be, it would be usefull for locating (and styling) a bridge location along a roadway, at least down to all but the highest level of resolution. Might also be a tunnel extraction method here with the right sort of DEM available. I also just thought of a question, in a high resolution environment (I have one foot contours/DEM data for our City), it might be beneficial to describe the line along it's length in some manner, where breaks in elevation occur, etc. Country and rural roads might not have breaks in them for some measure of distance, but have many vertical undulations along the space horizontal distance. bobb Andy Turner a.g.d.tur...@leeds.ac.uk wrote: Hi OSGeo Discussions, (cc Steve, Justin), In terms of the computing of viewsheds, both Steve Carver (http://www.geog.leeds.ac.uk/people/s.carver/) and Justin Washtell (http://www.comp.leeds.ac.uk/washtell/) have done some work on this, but I don't know the latest... It can be useful to compute which bits of road can be seen from other bits of road and what impact roads have on the perception of wilderness from off the road. Same true with vehicles on roads although these are usually moving. I think the viewshed work though is somewhat orthogonal to including elevation in routing application outwith surveillance and visual impact contexts. One further thought: it is much nicer to have junctions (where traffic is to slow and potentially stop for ordered inetrsection) well laid out at the top of small hills. This is for network flow and general economy and safety reasons. So in the analysis of a route, some quantification of junction impact taking into account elevation might be good. HTH Andy http://www.geog.leeds.ac.uk/people/a.turner/ -Original Message- From: discuss-boun...@lists.osgeo.org [mailto:discuss-boun...@lists.osgeo.org] On Behalf Of Stephen Woodbridge Sent: 14 September 2010 17:31 To: discuss@lists.osgeo.org Subject: Re: [OSGeo-Discuss] Thoughts on how to use elevation in routing On 9/14/2010 11:43 AM, Bill Thoen wrote: Steve, Adding viewsheds to the package would certainly up the computing costs; I was wondering if you had a limit to what sort of processing power you've got there. ;-) It is not unlimited, so part of the problem that is interesting to me is how to find and compute economical way to do it. I also think what you're proposing might be interesting, but you have to be careful about what conclusions you can draw from it. At what point does the cost due to gradient variations become insignificant to the overall cost of a route for a particular type of vehicle? For a trucker on an interstate highway it doesn't signify because the statistical noise of factors such high speeds and short driving time balanced against the higher price of fuel, services and road freight taxes completely overwhelms the cost factor contributed by the change in gradients. So in those cases you'd be computing numbers but not saying anything. Agreed, doing anything for the trucking industry that would be useful probably requires a lot more understanding of the industry and regulations required for that. Luckily it is not my main focus :) A different scenario, where gradient /is/ a significant factor, would be a three-day 100 mile bike ride event through the mountains (like the 'Ride the Rockies' event they hold around here every year.) The power that bicyclists can produce is so low that speeds and endurance are strongly affected by grades. But a bicyclist doesn't typically operate on the scale of the nation so applying the calculations to the entire TIGER file is overkill. Also, the bicyclist operates on such a large scale that the source data you're using to calculate gradient (30m DEM) may be too coarse to be reliable on the bicyclist's scale. Right, these points are all valid and have crossed my mind at one point or another. Applying this to the Tiger data set is not that big of a deal. I already have the Tiger data in XYZ so computing grades is not that difficult. Another reason for applying it to the whole data set is to build a web portal with US coverage. Granted any single route will not have continental scope, but
RE: [OSGeo-Discuss] UN FAO and FOSS / OSGEO Projects
Hi Noli, I am working full-time on the UO OSCAR software and am working towards making it available this year - its really a PhD reserach project. The original OSCAR prototype developed as part of the FAO project was built on top of UDig as a set of plug-ins - and these will eventually be rebuilt. The prototype was really just a proof of concept and screen shots are available in a couple of the reports/papers but not very interesting - see FIG. I have spent a lot of time since then working with OWL, Jena, and Pellet and happy to say that part is mostly complete. Currently I am working on web services for OSCAR and integration with WMS/WFS/GeoServer - since OSCAR does not use a database (for thematic data) this aspect is a little less straigh forward since these things tend to require 'up front' schemas. I do apologise for the out of date web site and the other delays but it's just me and my supervisors at the moment and funding is an issue. I will of course post to this list as things progress and am happy to answer questions. regards Geoff From: discuss-boun...@lists.osgeo.org [discuss-boun...@lists.osgeo.org] On Behalf Of Noli Sicad [nsi...@gmail.com] Sent: Wednesday, 21 July 2010 10:25 a.m. To: OSGeo Discussions Subject: [OSGeo-Discuss] UN FAO and FOSS / OSGEO Projects Hi, I am googling on the topic in GIS / mobile GIS for farming, forestry, forest management and forestry carbon applications I found out that Refractions did a UN FAO Mobile GIS System for Agriculture Monitoring. Mobile GIS System for Agriculture Monitoring – United Nations Food and Agriculture Organization http://www.refractions.net/expertise/casestudies/2005-12-unfao/ There is no screenshot of the software and no proper web link to the actual project which you can download the software. It is just www.fao.org. is this LGPL project? UN FAO probably sponsored some FOSS projects. I know that FAO sponsored the VB bindings for GDAL but I never saw the FAO project that uses this VB bindings - the actual FAO software / application. OSCAR is also sponsored by FAO. http://www.fao.org/docrep/012/i1447e/i1447e.pdf http://source.otago.ac.nz/oscar http://source.otago.ac.nz/oscar/OSCAR_Home Geoff, could we see a screenshot of OSCAR. http://www.mail-archive.com/discuss@lists.osgeo.org/msg05931.html I hope we can download OSCAR soon. Now, do you know any other UN FAO sponsored FOSS / Geo projects? Thanks. Regards, Noli ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
RE: [OSGeo-Discuss] Re: land records management with open source GIS
Hi I am working on an OSCAR implementation as part of my PhD study at Otago University in NZ[1]. This project started with initial funding from the FAO. Given the vagaries of the land administration domain, some approaches are heading down the path of simplification and harmonisation especially for the thematic data (parcel ownership etc) e.g.[2]. I am investigating the use of OWL (W3C) to allow variation in the 'schema' and 'process' to reduce the 'cost' of adaption and modification of software. I hope to be able to provide some OS components soon for others to look at, but the work isn't quite ready for this as yet. We do have a wiki for the initial project (https://source.otago.ac.nz/oscar/OSCAR_Home). This hasn't been maintained during the past year or so, but we are working towards adding to to the content and making updated code available for download. [1]www.fig.net/pub/fig2010/papers/ts04a5Cts04a_hay_hall_4519.pdf [2]www.fig.net/pub/fig2009/papers/ts06a/ts06a_lemmen_oosterom_etal_3282.pdf regards Geoff Hay From: discuss-boun...@lists.osgeo.org [discuss-boun...@lists.osgeo.org] On Behalf Of STEPHEN STANTON [sstan...@btinternet.com] Sent: Wednesday, 23 June 2010 10:56 a.m. To: OSGeo Discussions Subject: Re: [OSGeo-Discuss] Re: land records management with open source GIS Well yes, I was stretching Tanzania into southern Africa. OK, so my radar is currently being realigned. I'll tell you where it is tomorrow. Maybe. Steve --- On Tue, 22/6/10, P Kishor punk.k...@gmail.com wrote: From: P Kishor punk.k...@gmail.com Subject: Re: [OSGeo-Discuss] Re: land records management with open source GIS To: OSGeo Discussions discuss@lists.osgeo.org Date: Tuesday, 22 June, 2010, 22:06 On Tue, Jun 22, 2010 at 3:54 PM, STEPHEN STANTON sstan...@btinternet.com wrote: Hi Puneet, Now I'm having fun trying to guess where you're talking about! I just read about an ArcGIS-based pilot that was done a couple of years ago for Zanzibar - so is it Tanzania? You are off by a continent. SA = South America, not South African. In any case, Tanzania née Zanzibar would be Eastern Africa, no? ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
