Re: [OSM-talk] parcel data in OSM
On Tue, Feb 17, 2009 at 11:39:56PM -0800, Sam Vekemans wrote: > Hi, > ya, its certainly worth creating a tag proposal page for it. > I would (imo) would like to see it only rendered when zooming in real close. I would disagree that it should be rendered in the main maps at all. Surveyor data is not interesting to a typical map user, and it is much better suited for a specialized renderer, not for the general purpose map browsing that is offered by the main OSM map. > Some other renderer might want to see it at a different zoom. > When buying a house, you should know what land your getting :) And you can do that through specizlied applications for house buying (like Zillow). Regards, -- Christopher Schmidt MetaCarta ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Parcel Data in OSM?
Hi, Many city governments in Massachusetts publish their parcel (lot) data for free reuse, either individually or through MassGIS. This data is appropriately licensed for re-use in OSM, and is informative -- in most cases, it has addresses which can be used for geocoding. I'm curious as to whether people believe that this data of this type is appropriate for upload into OSM. There are clear technical reasons why this data might not belong in OSM -- the quantity of data is significant, and you can imagine that it could create a much larger database. At the moment, I'd rather address the social aspect of whether this data is appropriate to upload to OSM. A description of the data in question with regard to MassGIS is available at: http://www.mass.gov/mgis/parcels.htm Looking forward to hearing any and all opinions on this matter. Best Regards, -- Christopher Schmidt MetaCarta ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Talk-us] NHD Dataset
On Mon, Feb 16, 2009 at 12:55:51PM -0600, Ian Dees wrote: > It looks like the solution is to use Advanced Multipolygons: > > http://wiki.openstreetmap.org/wiki/Talk:Relation:multipolygon#Advanced_multipolygons > > Does anyone want to start writing an algorithm to nicely slice up polygons > into "small enough" chunks? So, to be clear, what this looks like to me is that for any polygon, you can take the 'one long way' that would previously have outlined it, and instead of having that 'one long way', you have as many little ways as it would take to make up that ring. So, for a 4,005 node way, assuming a 1,000 node limit, you could have: * 10 1,000 node ways * 1 5 node way and: However, it is not clear that that is what Frederik meant in: http://lists.openstreetmap.org/pipermail/talk/2009-February/034091.html He suggested that the ways should be split up into smaller 'ways of managable size', but from what I've seen, these 'ways of managble size' are often closed polygons on their own: http://openstreetmap.org/browse/way/24417625/ Doing the former is easy. Doing the latter is hard, because figuring out how far you can go before 'drawing a line' to close the polygon is something I can't understand how to do. Imagine a 'C' shaped lake: --- | | | | | | | | |-- Creating closed chunks of that polygon, keeping the edges mostly as they are in the original, is not something I can imagine a way to do programatically. (I think that tesslating it into a bunch of triangles would be possible, but then you're really creating something that doesn't look at all like the output polygon.) Maybe Frederik was saying that the former is okay. My curiousity in that case is just if renderers -- especially Mapnik -- will actually support these things. (I can't imagine it working for osmarender, but that is less concenring to me.) If they won't, then adding the data like this may not be a good idea, simply because people will start doing wacky things to get data to show up in the map, messing up data... Is my concern clear? If it's the former, it's pretty easy to add to polyshp2osm, but the latter is hard... CCing talk@, since I assume frederik isn't on this list, and he can probably quickly tell me that I'm wrong in thinkign he might mean the latter. :) Regards, -- Christopher Schmidt MetaCarta ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Up-to-Date, Minutely Mapnik Bookmarklet
On Thu, Jan 22, 2009 at 02:52:12PM +, Jon Burgess wrote: > 2009/1/22 Christopher Schmidt : > > On Thu, Jan 22, 2009 at 02:42:43PM +0100, "Marc Schütz" wrote: > >> > After a recent spate of OSM activity, especially with regards to > >> > rendering and so on, I've put together a bookmarklet designed to help > >> > visualize changes to OSM data in Mapnik more rapidly. > >> > > >> > http://labs.metacarta.com/osm/up-to-date/ > >> > > >> > "Using osmosis, osm2pgsql, and Mapnik, a bookmarklet which will draw the > >> > 'current' state of the database, delayed by less than 10 minutes. Simply > >> > press this button, and an image will be drawn over the map showing the > >> > current state of the database." > >> > > >> > You simply drag the bookmarklet to your browser bookmarks toolbar, and > >> > click it on any OSM map: InformationFreeway, main map, /browse/ pages, > >> > etc. > >> > > >> > I believe that all the kinks of this particular service have been > >> > worked out at this point, though I'm happy to take any feedback or > >> > criticism you have. (Please CC me on any important feedback.) > >> > >> Great work! > >> > >> However, the rendering rules seem to be different. For example: > >> > >> http://www.openstreetmap.org/?lat=49.9008&lon=10.89623&zoom=17&layers=B000TFTF > >> > >> The street "Klosterstraße" has the additional name "Main-Radweg" of a > >> cycleroute relation of which it is a member. > > > > The osm.xml files are largely the same (I think I'm out of date by a > > couple commits, but they're the same other than that). I'm using the > > default.style that ships with osm2pgsql, so maybe this is doing > > something different than the main site. > > > > The only other possibility that I'm not entirely sure of the likelihood > > of is that diff parsing has messed up this relation in some way. > > > > Anyway, thanks for the feedback; I have no immediate suggestions on a > > possible reason for this behavior. > > The osm2pgsql on the main site has a small tweak so that it does not > process any route relations. This was implemented a few months back > when people objected to these routes being shown. Is that in the default.style? Or is it deeper in the C code? (I guess another question is whether these routes are useful in the up-to-date view, since it is more of an 'editor' tool.) Regards, -- Christopher Schmidt MetaCarta ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Up-to-Date, Minutely Mapnik Bookmarklet
On Thu, Jan 22, 2009 at 02:42:43PM +0100, "Marc Schütz" wrote: > > After a recent spate of OSM activity, especially with regards to > > rendering and so on, I've put together a bookmarklet designed to help > > visualize changes to OSM data in Mapnik more rapidly. > > > > http://labs.metacarta.com/osm/up-to-date/ > > > > "Using osmosis, osm2pgsql, and Mapnik, a bookmarklet which will draw the > > 'current' state of the database, delayed by less than 10 minutes. Simply > > press this button, and an image will be drawn over the map showing the > > current state of the database." > > > > You simply drag the bookmarklet to your browser bookmarks toolbar, and > > click it on any OSM map: InformationFreeway, main map, /browse/ pages, > > etc. > > > > I believe that all the kinks of this particular service have been > > worked out at this point, though I'm happy to take any feedback or > > criticism you have. (Please CC me on any important feedback.) > > Great work! > > However, the rendering rules seem to be different. For example: > > http://www.openstreetmap.org/?lat=49.9008&lon=10.89623&zoom=17&layers=B000TFTF > > The street "Klosterstraße" has the additional name "Main-Radweg" of a > cycleroute relation of which it is a member. The osm.xml files are largely the same (I think I'm out of date by a couple commits, but they're the same other than that). I'm using the default.style that ships with osm2pgsql, so maybe this is doing something different than the main site. The only other possibility that I'm not entirely sure of the likelihood of is that diff parsing has messed up this relation in some way. Anyway, thanks for the feedback; I have no immediate suggestions on a possible reason for this behavior. Regards, -- Christopher Schmidt MetaCarta ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Up-to-Date, Minutely Mapnik Bookmarklet
On Thu, Jan 22, 2009 at 09:28:16PM +0800, maning sambale wrote:
> Nice and quick on firefox. But on safari:
>
> Safari can't use JavaScript for this action.
> Safari can't run the script "(function() { var s =
> document.createElement("script");
> s.src="http://labs.metacarta.com/osm/up-to-date/bookmarklet.js";;
> document.body.appendChild(s)})()" because Safari doesn't allow
> JavaScript to be used in this way.
>
> Still a nice piece of javascript.
What version of Safari? I'm using Version 3.1.2 (5525.20.1) on OS X
without problems.
> On Thu, Jan 22, 2009 at 9:18 PM, Steve Chilton wrote:
> > Very neat.
> > Works well and very quick.
> > I tested on something I did last night which shows fine, but it was a
> > coastal area and no land/sea (ie no coast showing) which is a little
> > disorientating (I was editing a river/coastline combination) so presume
> > it doesn't pick/use the relevant shapefiles.
> > Thanks for the work
> >
> > STEVE
> >
> > Steve Chilton, Learning Support Fellow
> > Manager of e-Learning Academic Development
> > Centre for Educational Technology
> > Middlesex University
> > phone/fax: 020 8411 5355
> > email: ste...@mdx.ac.uk
> > http://www.mdx.ac.uk/schools/hssc/staff/profiles/technical/chiltons.asp
> >
> > Chair of the Society of Cartographers: http://www.soc.org.uk/
> >
> > SoC conference 2008:
> > http://www.abdn.ac.uk/cartographers08/
> >
> > -Original Message-
> > From: talk-boun...@openstreetmap.org
> > [mailto:talk-boun...@openstreetmap.org] On Behalf Of Christopher Schmidt
> > Sent: 22 January 2009 12:09
> > To: talk@openstreetmap.org
> > Subject: [OSM-talk] Up-to-Date, Minutely Mapnik Bookmarklet
> >
> > Hi,
> >
> > After a recent spate of OSM activity, especially with regards to
> > rendering and so on, I've put together a bookmarklet designed to help
> > visualize changes to OSM data in Mapnik more rapidly.
> >
> > http://labs.metacarta.com/osm/up-to-date/
> >
> > "Using osmosis, osm2pgsql, and Mapnik, a bookmarklet which will draw the
> > 'current' state of the database, delayed by less than 10 minutes. Simply
> > press this button, and an image will be drawn over the map showing the
> > current state of the database."
> >
> > You simply drag the bookmarklet to your browser bookmarks toolbar, and
> > click it on any OSM map: InformationFreeway, main map, /browse/ pages,
> > etc.
> >
> > I believe that all the kinks of this particular service have been
> > worked out at this point, though I'm happy to take any feedback or
> > criticism you have. (Please CC me on any important feedback.)
> >
> > Best Regards,
> > --
> > Christopher Schmidt
> > MetaCarta
> >
> > ___
> > talk mailing list
> > talk@openstreetmap.org
> > http://lists.openstreetmap.org/listinfo/talk
> >
> >
> >
> > ___
> > talk mailing list
> > talk@openstreetmap.org
> > http://lists.openstreetmap.org/listinfo/talk
> >
>
>
>
> --
> cheers,
> maning
> --
> "Freedom is still the most radical idea of all" -N.Branden
> wiki: http://esambale.wikispaces.com/
> blog: http://epsg4253.wordpress.com/
> --
--
Christopher Schmidt
MetaCarta
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Up-to-Date, Minutely Mapnik Bookmarklet
On Thu, Jan 22, 2009 at 01:18:35PM +, Steve Chilton wrote: > Very neat. > Works well and very quick. > I tested on something I did last night which shows fine, but it was a > coastal area and no land/sea (ie no coast showing) which is a little > disorientating (I was editing a river/coastline combination) so presume > it doesn't pick/use the relevant shapefiles. Right, this is part of the 'real' reason behind the background color change: I dropped all the coastal shapefiles from my osm.xml, which is why I went with the white background. (Yes, I'm lazy.) Regards, -- Christopher Schmidt MetaCarta ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Up-to-Date, Minutely Mapnik Bookmarklet
On Thu, Jan 22, 2009 at 12:23:56PM +, LeedsTracker wrote: > 2009/1/22 Christopher Schmidt : > > http://labs.metacarta.com/osm/up-to-date/ > > Just tried it on a few places I updated last night, very smooth! > > In mapnik, some bits rendered slightly differently in style (e.g. base > background colour differs). This is intentional. When you zoom in or out, it's nice to see a difference between what is 'up-to-date' and what is not -- the way I've implemented that is with a background color change (from tan -> white). > Some names (e.g. of buildings or streets) > rendered differently to weekly mapnik too. Positioning, or text? Positioning may be different, because the image is not tiled in the same way, so I've seen things shift a little due to different available spacing. Regards, -- Christopher Schmidt MetaCarta ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Up-to-Date, Minutely Mapnik Bookmarklet
Hi, After a recent spate of OSM activity, especially with regards to rendering and so on, I've put together a bookmarklet designed to help visualize changes to OSM data in Mapnik more rapidly. http://labs.metacarta.com/osm/up-to-date/ "Using osmosis, osm2pgsql, and Mapnik, a bookmarklet which will draw the 'current' state of the database, delayed by less than 10 minutes. Simply press this button, and an image will be drawn over the map showing the current state of the database." You simply drag the bookmarklet to your browser bookmarks toolbar, and click it on any OSM map: InformationFreeway, main map, /browse/ pages, etc. I believe that all the kinks of this particular service have been worked out at this point, though I'm happy to take any feedback or criticism you have. (Please CC me on any important feedback.) Best Regards, -- Christopher Schmidt MetaCarta ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Improvements to Massachusetts Data
On Wed, Jan 07, 2009 at 07:22:27PM -0600, Ian Dees wrote: > On Wed, Jan 7, 2009 at 7:06 PM, Christopher Schmidt > wrote: > > > > > The next big task is to get water uploaded: probably using: > > > > http://www.mass.gov/mgis/hd.htm > > http://www.mass.gov/mgis/wetdep.htm > > > > I haven't done much planning on this yet, but I will be doing it at: > > > > http://wiki.openstreetmap.org/wiki/MassGis_Layer_Water > > > Chris, > > Take a look at the talk-us list from a while ago. We started talking about > importing the national hydrography dataset, which should include the water > layer and be at least as good on a state-wide basis. > > In fact, I spent some time today looking at my shp-to-osm tool's mappings to > import the NHD dataset. Perhaps we should do a mind-meld on our ideas... Really, the quality is at 1:25k? I'm surprised; but if so, pleasantly, and I'll go with it. http://boston.freemap.in/?zoom=1&lat=903738&lon=140626&layers=B Has an example of MA water... Regards, -- Christopher Schmidt MetaCarta ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Improvements to Massachusetts Data
Hi, After some urging by TimBL, I put some more work into uploading some new data in Massachusetts. There are two new imports of import: * Buildings Layer, http://www.mass.gov/mgis/lidarbuildingfp2d.htm This layer contains building outlines for all of Metro Boston. There are no attributes attached to the data. (However, for state-run agencies like fire stations and the like, the node is usually in the center of the way, generating a reasonable look.) Cambridgeport, my home neighborhood: http://openstreetmap.org/?lat=42.36259&lon=-71.10386&zoom=15&layers=B MGH, original home of the "MUMPS" programming language that powers osmxapi: http://openstreetmap.org/?lat=42.362927&lon=-71.069152&zoom=18&layers=B Fenway Park, home of the Boston Red Sox: http://openstreetmap.org/?lat=42.34671&lon=-71.09761&zoom=17&layers=B The tool used to upload this data was polyshp2osm, a new-style upload script that has support for namespaced source data attributes, and (unlike my previous shape uploading tool) is nicely documented, and checked into OSM SVN at: http://svn.openstreetmap.org/applications/utils/import/shp2osm/polyshp2osm.py This tool supports polygons-with-holes via the 'multipolygon' relation, which is useful for buildings like Camridge Friends School: http://openstreetmap.org/?lat=42.387965&lon=-71.130515&zoom=18&layers=B When uploading, unfortunately, I did not sufficiently check all data, and of the 300,000+ buildings imported, 9273 were duplicated, exactly, in the source data. These uploads made it into the upload, but I have since deleted them, so there should not be many of these left. I apologize for the temporary inconvenience. -- The real reason I started working on this project with Tim, however, was to get the green space in Massachusetts updated. This took a bit more effort, because there is a large quantity of data attached to each greenspace feature, as described on: http://wiki.openstreetmap.org/wiki/MassGis_Layer_Openspace The end result is that Massachusetts is much more 'green' than it used to be: http://openstreetmap.org/?lat=42.304&lon=-72.09&zoom=9&layers=B When uploading, a choice was made to use leisure=recreation_ground, when what should probably have been used was landuse=recreation_ground, so many areas that were unspecified "recreation areas" -- which range from parks to state forests -- are currently not green on the map. r13029 adds this rendering to the Mapnik stylesheet, with Steve8's support, and so the next time there is a style update, many of these 'recreation' areas should start showing up. However, many recreation_ground areas in Massachusetts really have better possible tags -- many of them are, for example, actually parks. Some of these changes can be automated: I'm currently working on a conversion tool to read all leisure=recreation_ground tags that I created and convert them to leisure=park if the item has 'Park' in its name. Another common name which will get renamed is places with "Golf Course" In the name. (I'm also interested if anyone has a suggested tag for country clubs? I didn't see anything relevant in the wiki or tagwatch.) Each of these uploads had each of its 50 files manually opened in JOSM, and compared against existing data. Conflicts were merged by hand; generally deleting the data from the new upload, rather than from the existing data, thugh in some cases significantly more accurate places were uploaed in place. I apologize if I have missed any merges in this way; this was a many-many-hours task, so I may have missed some. The next big task is to get water uploaded: probably using: http://www.mass.gov/mgis/hd.htm http://www.mass.gov/mgis/wetdep.htm I haven't done much planning on this yet, but I will be doing it at: http://wiki.openstreetmap.org/wiki/MassGis_Layer_Water I want to comment that I have been extremely pleased with the results of both Osmarender and Mapnik at styling these polygons: I find them to be quite nice in both cases. So good work to everyone involved in both cases. (And probably to some Germans for adding enough buildings to make building rendering important ;)) Best Regards, -- Christopher Schmidt MetaCarta ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Relation/Routes and Hikes in open Country
On Fri, Jun 27, 2008 at 10:59:49AM -0400, [EMAIL PROTECTED] wrote: > > > > > Yep that looks like it figures. I'll have to set up either a local 'http:' > > copy of the data or a proxy as you suggest. Shame though, because both of > > these make it harder for a 'mashup artist' to use relations and render > > them on top of a slippy map. > > > > Still doesn't work, and I don't speak JavaScript to work out what's wrong. > > I put a copy of the script pointing to a data file (on the same server) here: > http://www.mungewell.org/osm/osm.html > > Any other suggestions? Add a 'projection: map.displayProjection' in the options of your GML layer, by your format object. Right now, your data is off the coast of Africa. Regards, -- Christopher Schmidt MetaCarta ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] OpenLayers and Proxy (was :Relation/Routes and Hikes in open Country)
On Thu, Jun 26, 2008 at 10:25:27PM +0200, Frederik Ramm wrote: > Hi, > > Thomas Wood wrote: > > I think you're running into XSS limitations of browsers. You'll > > probably need to proxy the request on the same domain thats hosting > > the page. > > Someone talked to me about this at the LinuxTag. He was adamant that our > API should support JSON (in addition to XML) as a return data format. He > said that a JSON message would be valid JavaScript and thus it could be > loaded
Re: [OSM-talk] Relation/Routes and Hikes in open Country
On Thu, Jun 26, 2008 at 07:18:33PM +0100, Thomas Wood wrote: > On Thu, Jun 26, 2008 at 6:31 AM, Simon Wood <[EMAIL PROTECTED]> wrote: > > On Wed, 25 Jun 2008 16:01:40 -0400 > > Christopher Schmidt <[EMAIL PROTECTED]> wrote: > > > >> The OpenLayers parser doesn't do anything with relations themselves -- > >> it wouldn't group the bits together into a single feature -- but it > >> would take the ways and nodes and draw them into the map. > >> > > > > I spent the evening trying to get this to work. I get the underlying map > > OK, but no matter what I try I can't get the OSM data overlaid on it :-( > > > > Best I can make out is that it is failing (siliently) to load the data. > > > > Attached is my attempt... > > Simon > > I think you're running into XSS limitations of browsers. You'll > probably need to proxy the request on the same domain thats hosting > the page. > I also think that the protocol in the url is mandatory. > > At a quick glance, the rest seems like it would work. See http://trac.openlayers.org/wiki/FrequentlyAskedQuestions#ProxyHost for how to set up a Proxy in OpenLayers. Regards, -- Christopher Schmidt MetaCarta ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Relation/Routes and Hikes in open Country
On Wed, Jun 25, 2008 at 02:21:10PM -0400, [EMAIL PROTECTED] wrote: > > > >> Something I keep toying with is the idea of facilitating mashups (did > >> I really just say that?) by giving masher-uppers a way to tie their > >> routes to OSM IDs. > > > > There is an example on OpenLayers showing how to superimpose an OSM file > on top of a slippy map. > http://openlayers.org/dev/examples/osm-layer.html > > The overlay looks like it is just a normal osm file > (http://openlayers.org/dev/examples/osm/sutton_coldfield.osm). I wonder if > this would work with a 'full' relation file (ie. > http://www.openstreetmap.org/api/0.5/relation/18321/full). The OpenLayers parser doesn't do anything with relations themselves -- it wouldn't group the bits together into a single feature -- but it would take the ways and nodes and draw them into the map. Regards, -- Christopher Schmidt MetaCarta ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
[OSM-talk] tilesathome, osmxapi
One of the machines attached to Hypercube is going down for maintenance: there will be some apache downtime and tilesathome upload processing will be turned off for part of the time. The maintenance is supposed to be approximately two hours: I will email the list when everything is back up. Regards, -- Christopher Schmidt MetaCarta ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] osmxapi problems?
On Wed, Jun 11, 2008 at 09:45:46PM -0400, Christopher Schmidt wrote: > On Wed, Jun 11, 2008 at 04:49:00PM -0700, Alan Millar wrote: > > Anyone else having osmxapi problems? > > > > I can't generate lowzoom captions because it is returning empty data. > > > > For example: > > > > wget > > 'http://www.informationfreeway.org/api/0.5/node[place=town|city|country][bbox=-123.046875,46.878726,-110.234375,50.151377]' > > > > comes back with one xml header line then it closes the connection and file. > > > > Any ideas? Thanks. > > A disk filled up, and is being problematic to clean up (since the disk > is 100% full, it can't get an NFS lock written, I think, so it's not > letting me remove files). > > I'm working on getting it back up. The disk issus are resolved; unfortuantely, I can't seem to get osmxapi's backends to respond to anything. I think this one will call for Etienne's intervention. Regards, -- Christopher Schmidt MetaCarta ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] osmxapi problems?
On Wed, Jun 11, 2008 at 04:49:00PM -0700, Alan Millar wrote: > Anyone else having osmxapi problems? > > I can't generate lowzoom captions because it is returning empty data. > > For example: > > wget > 'http://www.informationfreeway.org/api/0.5/node[place=town|city|country][bbox=-123.046875,46.878726,-110.234375,50.151377]' > > comes back with one xml header line then it closes the connection and file. > > Any ideas? Thanks. A disk filled up, and is being problematic to clean up (since the disk is 100% full, it can't get an NFS lock written, I think, so it's not letting me remove files). I'm working on getting it back up. Regards, -- Christopher Schmidt MetaCarta ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] AfricaMap
On Fri, May 23, 2008 at 06:30:31PM +0100, John McKerrell wrote: > Ben spoke at one of the evening "Bird's of a Feather" sessions about > AfricaMap. They have various goals for the project, but the first is > to digitise and georeference the maps of Africa that they have > available within the Harvard vaults. He seemed very open to the idea > of making these maps available then through WMS layers or tiles so > that we could then derive maps from them. Andrew Turner was also there > and fired a few questions at him. I wrote some notes about the > discussion here: They're likely going to be using TileCache and Spherical Mercator, based on my current understanding of the project, so tiles should be available and reusable within Potlatch if they end up going that route. Regards, -- Christopher Schmidt MetaCarta ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Please restore deleted suburb
On Thu, May 22, 2008 at 11:28:30AM -0400, Jason Woofenden wrote: > Braintree, a suburb of Boston, MA, USA is blank, except for POIs and the > subway. Could someone please restore it? > > Here's the affected area on the slippery map: > http://openstreetmap.org/?lat=42.1952&lon=-71.0147&zoom=13&layers=B0FT It wasn't deleted, it was never uploaded. The MassGIS data for the area was incorrect in a way that it failed the conversion process that we were using. To be honest, I find it somewhat difficult to care about people way down in Braintree -- I mean, really, it's on the other side of the river ;) More seriously, I can try and find some time to fix up the code so that it parses braintree correctly. Regards, -- Christopher Schmidt MetaCarta ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] unable to download data
On Thu, May 15, 2008 at 05:42:59PM +0530, Kenneth Gonsalves wrote: > hi, > > I tried this: > > http://api.openstreetmap.org/api/0.5/map?bbox=11.10,76.48,11.54,76.93 > in order to download data, but all I get is this error message: > > > This XML file does not appear to have any style information > associated with it. The document tree is shown below. > > > > what am I doing wrong? That's not an error message, that's just how Firefox displays most XML documents. The fact that the OSM tag is emmpty just means there's no data in that area. Regards, -- Christopher Schmidt MetaCarta ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] [OSM-dev] Online/offline slippy map finished.
On Fri, May 09, 2008 at 07:08:51PM +0200, Raphael Studer wrote: > Hi Sebastian, > > I get a lof of errors like that: > > > File "/usr/lib/python2.5/socket.py", line 249, in flush > self._sock.sendall(buffer) > error: (32, 'Broken pipe') > > > Does anyone know where they come from? "BaseHTTPServer + Browser sucking". Essentially: * If you load an image, and then replace it (as OpenLayers does) it saves the browser a lot of work * BaseHTTPServer treats all cases where the remote end closes the connection as a Broken Pipe * BaseHTTPServer complains noisily about Broken Pipe exceptions. In the end, they're nothing to worry about. Regards, -- Christopher Schmidt MetaCarta ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] [OSM-dev] Online/offline slippy map finished.
On Fri, May 09, 2008 at 04:09:28PM +0200, Juan Lucas Dominguez Rubio wrote: > lol, thank you Sebastian for that code. I have tested it on Windows XP and > the only problem is that images are not shown, everything else seems to be in > place. I don't think it's because of using / instead of \. Apparently the > HttpServer only delivers the first bytes of the PNG files, and then closes > the connection. I have tried to add the file length and proper file type in > the header but it still closes the connection too soon. > > wget.exe is unable to get the whole image file either. > I'll keep on trying, lol On Windows, all Python read/writes have to be opened with "rb"/"rw" instead of "r"/"w". Changing Line 36 to: f = open(installpath + path, "rb") Might do it. Regards, -- Christopher Schmidt MetaCarta ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] OSM XAPI - help!
On Thu, May 08, 2008 at 02:15:44PM +0100, elvin ibbotson wrote: > > > >From: Steven te Brinke <[EMAIL PROTECTED]> > >Date: 8 May 2008 11:31:43 BDT > >To: elvin ibbotson <[EMAIL PROTECTED]> > >Cc: talk@openstreetmap.org > >Subject: Re: [OSM-talk] OSM XAPI - help! > > > > > >Delivering data as an attachment is just adding one header to tell > >the browser that it should present it as an attachment to the user. > >Thus the content is the same as if it wasn't an attachment. The php > >function file() works fine, as should any other function. > > This doesn't seem to be what's happening here. There is a header > indicating the data is included in an attachment: > Content-Disposition: attachment; filename=data.osm That's just a header. It doesn't mean anything. > The html file itself does not include the OSM data, just some stuff > about the parameters of the call, copyright, etc. > If I call the xapi script using a browser it downloads the data.osm > file but if it is called from my own PHP script (on my server) I just > get the html file and not the data file. There is no "HTML file". What you're probably getting is the XML header, which is delivered immediately, and your connection is timing out before you load the rest of the data: osmxapi delivers a header immediately, and then delivers the rest of the data as it becomes available. I would investigate the timeouts on the connection mechanism you're using. Regards, -- Christopher Schmidt MetaCarta ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] zoom yahoo data in potlatch?
On Sat, May 03, 2008 at 09:30:39AM +0200, bvh wrote: > On Fri, May 02, 2008 at 10:40:42PM -0400, Christopher Schmidt wrote: > > > > in options, choose 'Aerial - OpenAerialMap' as background and you'll be > > > > fine > > > > > > hmm, i'm slightly baffled by that. the oam coverage for nz is > > > appalling at best and as an aside, i'd be very surprised if it was > > > better resolution than the yahoo imagery anywhere on the planet > > > > In the majority of the world, OAM and Yahoo! imagery are the same -- > > both based on Landsat. The difference, in those areas, is that OAM will > > display tiles far above "1:1" ratio, as opposed to just giving a 'no > > data' message. > > > > Additionally, I highly doubt you will see anything higher resolution > > than > > http://openaerialmap.org/map/?lat=37.79202&lon=-122.32715&zoom=21&layers=BF > > in Yahoo! anywhere on the planet. > > I am not local, but the openstreetmap.org data at the north side of the > canal does not seem to match what is on the imagery? More specifically > the raster of streets seems out of place. The OSM data in OAM is 6 months out of date, if that's what you're referring to... It's probably already fixed in OSM. Regards, -- Christopher Schmidt MetaCarta ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] [OSM-dev] The future of Potlatch
On Sat, May 03, 2008 at 06:56:40AM +0100, Lester Caine wrote: > SteveC wrote: > > On 2 May 2008, at 12:38, Christopher Schmidt wrote: > >> Some things don't require referential integreity: selecting ways/nodes > >> within a bounding box can't hurt the referential integrity of the > >> database (so long as the code is well-maintained), so the harm in > >> converting those methods (which are probably the single most > >> performance > >> important aspect of Potlatch?) to SQL is relatively low, so far as I > >> can > >> tell... > > > > One of the other reasons for moving to rails was the holy grail of > > using postgres, and rails is theoretically db independent. Of course > > it didn't work out that way. > > Main problem here is the lack of good 'GIS' in other databases. It looks like > I may be forced to move the gis data to a postgres database despite the fact > that I have had all other systems running Firebird/Interbase for 15 years :( But the backend of OSM matters little, in that case. You could say, in the same way, that OSM should be topographical (instead of topological) because databases don't support topology well. But that doesn't make sense: OSM is an API designed to allow people to collect the data: Not a GIS system designed to allow people to interact with the data with GIS tools. That aspect of it can easily come on top of OSM. > > On the specific point, I'm all for more speedy SQL on things like that > > so long as there is a rails logic way too - in much the same way as > > there apparently is with the tileid stuff. Then if things change > > significantly (like, say with changesets, rollback, spatial data > > types) we don't have limited options. > > Rails may be nice for some, but for those of us how are coding other > applications daily without any reference to rails it is a turn off. This is true in *any* language. There's nothing that everybody knows how to code for: Rails is popular, so this is much less true than in the days before the server was written in Ruby. > I do not have the time to bother even looking which is a reason that I > have not been able to contribute on that side. I work with raw data > via SQL and will continue that way with 25 years of C++ applications > and now increasingly PHP. So any extensions I come up with ( such as > NLPG data interface ) will be in PHP :) Which is fine: it just means that you don't hack on OSM.org. This is true of the majority of OSM contributors and developers. Regards, -- Christopher Schmidt MetaCarta ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] zoom yahoo data in potlatch?
On Fri, May 02, 2008 at 08:19:52PM -0700, David Muir Sharnoff wrote: > You're right: that OAM imagery is very detailed. Unfortunately, it's > not that good where I'm mapping. Sorry, my comments were tongue in cheek. I don't expect there to be many cases where OAM is the best choice for mapping. > Richard, can you add the please? Richard is likely limited by the Yahoo! Flash API: I expect that there's a fair chance that Yahoo! hasn't updated their Flash API to provide the new zoom levels that the main API added 2-3 weeks ago (Yahoo added more zoom levels worldwide at that time). (Of course, Richard will tell me if I'm wrong, I'm sure :)) Regards, -- Christopher Schmidt MetaCarta ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] zoom yahoo data in potlatch?
On Sat, May 03, 2008 at 12:51:43PM +1200, Robin Paulson wrote: > 2008/5/3 micha ruh <[EMAIL PROTECTED]>: > > in options, choose 'Aerial - OpenAerialMap' as background and you'll be fine > > hmm, i'm slightly baffled by that. the oam coverage for nz is > appalling at best and as an aside, i'd be very surprised if it was > better resolution than the yahoo imagery anywhere on the planet In the majority of the world, OAM and Yahoo! imagery are the same -- both based on Landsat. The difference, in those areas, is that OAM will display tiles far above "1:1" ratio, as opposed to just giving a 'no data' message. Additionally, I highly doubt you will see anything higher resolution than http://openaerialmap.org/map/?lat=37.79202&lon=-122.32715&zoom=21&layers=BF in Yahoo! anywhere on the planet. Regards, -- Christopher Schmidt MetaCarta ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] [OSM-dev] The future of Potlatch
On Fri, May 02, 2008 at 12:27:38PM +0100, Tom Hughes wrote: > > I won't pretend that I know nearly as much about the rails code as you > > do, but it seems like some of these would be better abstracted out. If > > that were the case -- that is, that all the Rails code on the site used > > the same underlying methods to talk to the database, given a 'fixed' > > API, and amf_controller was just about encoding the returned data into > > AMF -- then I thiink it would be possible to change the underlying slow > > methods into SQL (after proper profiling), because the main reason not > > to is 'maintaining two different codebases sucks', rather than 'no one > > likes SQL over rails'. > > If I thought Steve would let me get away with doing raw SQL instead > of using the rails object model I might have done so long ago ;-) > > Doing so would bypass all the integrity checks though, which is > bad - that's a side effect of having the integrity checks in the > wrong place (the rails object model rather than the database). Some things don't require referential integreity: selecting ways/nodes within a bounding box can't hurt the referential integrity of the database (so long as the code is well-maintained), so the harm in converting those methods (which are probably the single most performance important aspect of Potlatch?) to SQL is relatively low, so far as I can tell... Regards, -- Christopher Schmidt MetaCarta ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] [OSM-dev] The future of Potlatch
On Fri, May 02, 2008 at 08:35:06AM +0100, Tom Hughes wrote: > To summarise I think we both want the same thing, but you perhaps > think somebody should just sit down and bang an AMF version of the > current XML API and I'm happy with trying to incrementally move > towards that position? Well, I don't think that's how I would put it. I think you were slightly oversimplifying when you just said "It's a few lines of Rails object code." Some of the request methods in Potlatch are at least a bit more complex than that. getway_old, for example, is slightly more complex than that, as is putway. I won't pretend that I know nearly as much about the rails code as you do, but it seems like some of these would be better abstracted out. If that were the case -- that is, that all the Rails code on the site used the same underlying methods to talk to the database, given a 'fixed' API, and amf_controller was just about encoding the returned data into AMF -- then I thiink it would be possible to change the underlying slow methods into SQL (after proper profiling), because the main reason not to is 'maintaining two different codebases sucks', rather than 'no one likes SQL over rails'. The fact that Potlatch was using SQL was unfortunate, but for some problems, that could be the right solution. The fact that the API was *not* was what I would see as the real problem -- and changing the architecture so that that wouldn't happen for the same task seems valuable to me, or at least heading in that direction. Perhaps you were already heading there; I don't really know what the plans are for rails_port development, so I'm probably off my rocker :) Perhaps I'm wrong on this stuff: as I said, I'm new to the rails world. At this point, putting my code where my mouth is is probably the right choice, so until I sit down and hack on stuff, it's fine to ignore what I'm saying :) I'll see if I get time to have a play this weekend and improve my knowledge and understanding of the code, and maybe I'll find that you're right, and there's no reason to bother. Regards, -- Christopher Schmidt MetaCarta ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] [OSM-dev] The future of Potlatch
On Fri, May 02, 2008 at 12:24:35AM +0100, Tom Hughes wrote: > In message <[EMAIL PROTECTED]> > "Tom Carden" <[EMAIL PROTECTED]> wrote: > > > I think the fact that it has its own API is a much bigger concern than > > it being written in AS 1.0 is. If Potlatch was using the main API, > > development of API-backed features in Potlatch could be shared by > > other editors too. Any tests written for the API would help Potlatch. > > Any changes to the schema would only have to happen once. etc. etc. > > I think most of us (with the possible exception of Richard) would > agree here. > > Well actually I don't mind the existence of the AMF API as such so > long as it is just concerned with decoding the RPC calls and encoding > the results, and it uses the rails object model to do all the work > so that important code is shared with the XML API. There's an important difference between this and "Potlatch using the main API". There are, I believe, some things that Potlatch can do that no other client can do, because the API to do it is not available. Specifically: * whichways_deleted gets deleted ways in a bbox, which the main API doesn't provide * getway_old has a "last deleted version", which seems different More problematic than the specific methods which do or don't exist, however, is the fact that the Potlatch way of interacting with them is *entirely* different -- so when a bug is fixed in the main API, the fix has to be duplicted in the Potlatch/amf_controller. This affects development of the server side APIs. You, at one point, put forward a significant amount of effort in improving the Rails code in amf_controller: that work benefited only Potlatch. If Potlatch was using the same backend rails calls (rather than just objects/models), then that development time could have benefited other clients as well. Potlatch has a very different way of interacting with the API. This way of interacting with the API has some benefits, and could allow for other clients similar to Potlatch to be developed without being tied explicitly to amf_controller, which is (at least at the moment) essentially Potlatch specific. (Things like 'masterscale' and 'potlatch_lon' seem to be indicate this anyway: maybe I'm wrong here.) I don't know amf: I see from the code that it's Actionscript Message Format. If there is a desire for supporting Actionscript Message Format for API actions, I don't see a problem with that at all: In fact, other encodings of OSM data delivered via the API seem a natural progression to me. (I'm biased here, having done this with TileCache, FeatureServer, WPServer, etc.) But I don't see that that means that Potlatch should have access to API methods which simply don't exist to any not potlatch-clients (or that clients would have to speak the same language as Potlatch to use them). > We have in fact started moving towards that goal with some work > that Steve did on some of the AMF calls. This is a different goal, that of replacing SQL with rails objects. A valuable goal, but not the same as abstracting the data selection calls to a single set of code, and then using that code to serve both the main API and amf_controller. > The problem is that it turned out that, even after I had optimised > the code, it is significantly slower to go through the rails object > model that to make direct SQL queries. This is interesting, but (imho) less relevant: The value of the above is actually doubled by this statement, since if Potlatch and the API were using the same function, one could optimize this, and since the code is used by *all* clients (not just one) you would see any problems with SQL calls more generally, and perhaps find it easier to debug them. (I think this is compounded by the fact that AMF is a format which is hard to replicate outside of a flash client, which makes server side developers less likely to have the technical chops to debug them.) A common library for API functionality between amf_controller and the various api_controller methods would help resolve this to some extent. > I think even Richard wouldn't mind too much making the AMF API use > the rails object model if it wasn't for the performance issues. Using the Rails Object Model is solving an *internal* API issue, but there still continue to exist two external APIs that use different backend data manipulation to achieve their goals. This seperation is what I see as more problematic -- and I think that's what Tom was addressing as well, though I could be wrong. Regards, -- Christopher Schmidt MetaCarta ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] OSM planet
On Mon, Apr 28, 2008 at 07:19:06PM +0530, Subhodip Biswas wrote: > hi ! > > OpenStreetMap is growing ranging from mappers to developers ,users etc . > There is a section called User Diaries in openstreetmap.org . > Why cant we have something called OSM planet . I.e using planet to > integrate already existing blogs from users and make a feed out of it Like: http://planet-osm.shaunmcdonald.me.uk/ Regards, -- Christopher Schmidt MetaCarta ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Static maps using the new export function
On Fri, Apr 25, 2008 at 02:11:29PM +0100, Tom Hughes wrote: > In message <[EMAIL PROTECTED]> > Frederik Ramm <[EMAIL PROTECTED]> wrote: > > > Christopher Schmidt wrote: > > > Assuming that the export tab exported a simple, copy-paste friendly HTML > > > view, would that help solve the technical hurdles? > > > > You mean to create a HTML snippet that would, with some stylesheet > > magic, load a fixed map section from the tile server (including partial > > display of border tiles)? That would be really cool - and could be used > > even for embedding it into non-Javascript sites. > > I think Chris meant (and it was certainly my plan) an HTML snippet > that embeds an OL slippy map. Though I guess if you turned off the > default controls you might be able to make it static. Right, there's that option, or you can just take the HTML that would end up being generated by OpenLayers for such a static map, and use that instead. I mean, it's Just Code, after all :) You're right though, that I was thinking about the slippy map case, and not the static map case. Regards, -- Christopher Schmidt MetaCarta ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] namespaces and copyright
Further discussion on this topic is probably best relegated to the legal-talk list: http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/legal-talk On Fri, Apr 25, 2008 at 01:23:05PM +0100, elvin ibbotson wrote: > Chris Hill is worried about copyright issues with climbing routes and > this is like lots of concerns I have seen expressed such as taking > street names from actual street signs rather than from copyrighted > material. If it's the name of the street, it's the name of the > street, no matter how or where it is communicated. Not only am I not > an expert on databases but I am equally ignorant of the finer points > of copyright law. But PLEASE! A street name cannot be copyright and > printing it on a piece of paper or causing it to appear on a screen > is hardly the stuff of intellectual property. Copyright isn't the ony kind of intellectual property. In general, copying *one* street name off of a map would certainly not be a violation of coypright -- you can't copyright facts -- but you can (in the UK, and other parts of the world) hold intellectual property in *collections of facts* (typically referred to as 'database right'). This means that deriving the 'one' street is not a violation, but deriving many could be seen to be a 'significant extract' which is in violation of those database rights. As I said, the legal-talk list is the best place to continue discussion on this topic, but it's not as clear cut and simple as it would be wonderful for it to be. >If not, I would like to see them sue. This statement is exactly the *opposite* of what the OSM Foundation probably feels. Lawsuits cost money. OSM doesn't have the kind of resources that allow it to consider defending a suit a reasonable path at this time, and thus, it takes the 'moral high ground' by avoiding all the issues involved and playing it completely safe, as is the best position for a project of this nature to take. Regards, -- Christopher Schmidt MetaCarta ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Static maps using the new export function
On Fri, Apr 25, 2008 at 12:13:25PM +0100, Tom Chance wrote: > > Hi, > > On Fri, 25 Apr 2008 12:03:46 +0100, Tom Hughes <[EMAIL PROTECTED]> wrote: > > In message <[EMAIL PROTECTED]> > > Tom Chance <[EMAIL PROTECTED]> wrote: > >> I can't see an obvious way to do this, maybe I just need to dig around > > in > >> the code behind the export tab, but is it possible to already do > > something > >> similar to the Google static maps feature, i.e. allow people to just > >> specify a URL in an img tag and have the static image with optional > > marker > >> automatically created? > >> > >> http://code.google.com/apis/maps/documentation/staticmaps/ > >> > >> If not, how much work would it be & how hard? > > > > There is a way to do it, as a little exploration of the export feature > > would doubtless show, but I don't want people doing that sort of thing > > as it is not designed to support that sort of load. At the moment > > there are no technical restrictions, but if it becomes a problem then > > there will be. > > OK, thanks for letting me know. > > > > Is an OpenLayers slippy map pointed at our tile server not better there? > > I think so, but I suppose it's another technical hurdle and static images > would be much easier for a lot of people. Something for the future, then. Assuming that the export tab exported a simple, copy-paste friendly HTML view, would that help solve the technical hurdles? Regards, -- Christopher Schmidt MetaCarta ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Tagging climbing routes and scrambles
On Thu, Apr 24, 2008 at 01:23:32PM +0100, Steve Hill wrote: > On Thu, 24 Apr 2008, Christopher Schmidt wrote: > > >I can't claim to have the right answer, but I will state that it is not > >common in geographic software to have namespaced attributes: in general, > >when this is the case, it is a namespace based only on the object type > >which has a specific schema. (In this case, that would be something like > >pisteLift, since the dataset would be a list of pisteLifts.) > > But in common software, do the objects have an explicit type? In > OpenStreetMap they do not - the type is determined by a bunch of arbitrary > tags, for which you need background knowledge of which tags define the > object type and which just define attributes (e.g. there is no unified > "type" tag which you know will always define what the object is). In general, yes, objects are put into a specific database table or some such because they have a specific type with a known set of tags. This isn't really much different than well-curated OSM data, which typically makes it entirely possible to do this using hueristics. It almost sounds like the proposal is to use namespaces in place of a 'type' property on the object... which I personally think would be a better way to go than to namespace every tag... Regards, -- Christopher Schmidt MetaCarta ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Tagging climbing routes and scrambles
On Thu, Apr 24, 2008 at 12:51:13PM +0100, Steve Hill wrote: > > piste:lift:occupancy -- wtf? this can only ever happen on a piste:lift > > right? there is absolutely zero point in this tag.. call it occupancy > > -- the result is 100% identical. This is purely namespace wanking for > > the sake of it. It serves no purpose. None. Zip. Nada. The only thing > > this does is make the tag name very long, > > Of course it serves a purpose - it tells you that the value of the tag > describes the occupancy of a lift. An "occupancy" tag could be used to > describe attributes of different types of object - number of people in a > building, number of fish in a pond, etc. Without the name space you need > to get the context from somewhere else (one of the other tags... which > one?) to make it meaningful. I think that this is the crux of the entire difference in opinions. There appear to be two main points of view: * The tags describe an instance of an object * The usage of the tags on an object should be looked at as a whole * There is no need for namespacing except in cases where (on a single object) the same key can be used multiple times (a la name:en, name:cy, etc.) And the other: * Tags are properties in a global namespace * A given tag should have a single meaning throughout all of the data; if something has a piste:lift:capacity tag, you can tell it is a piste:lift * There is need for namespacing in order to prevent collisions on tags of the same name on different types of objects. I can't claim to have the right answer, but I will state that it is not common in geographic software to have namespaced attributes: in general, when this is the case, it is a namespace based only on the object type which has a specific schema. (In this case, that would be something like pisteLift, since the dataset would be a list of pisteLifts.) That use case can be trivially built up when it's needed based on the other data in the OSM database. I don't really understand why there is a need to have a global definition that a given 'key' has a specific meaning in all contexts, which appears to be the reason for namespacing. It seems to me that creating 'object' definitions that describe objects and their common/useful keys would be most useful from a 'geo' point of view. I can give more examples of what I mean by this if it's neccesary/helpful. Regards, -- Christopher Schmidt MetaCarta ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] OSM on "factory" Macs
On Mon, Apr 21, 2008 at 10:46:53PM +0200, Frederik Ramm wrote: > My question to the Mac users out there: Will those Macs be suitable > for demonstrating all important aspects of OSM, i.e. > > * Slippy Map (heard rumours that it runs sub-optimal on Safari, > always loading tiles for all layers instead of current only?) I've heard this rumour as well, but use Safari as my primary browser and have never had this issue. Safari 3.1 is 2x faster than FF3 and 10x faster than FF2 at DOM manipulation, so in general, the slippy map will be much faster on latest Safari than any other browser on mac. > * JOSM (especially concerned about usability with 1 button mouse) This is likely your sticking point. The inability to drag the map is a real killer on JOSM, and I'm not aware of any decent ways of working around it within the java on mac. (I do a *lot* of zooming in and out, and use of the ctrl-arrows, whenever I need JOSM without an eexternal mouse.) > * Potlatch Potlatch works great, and is primarily developed on an apple machine. > * ...? The PDFs from the export tab all work beautifully in Apple's 'Preview.app'. > Or will I have to install countless helpers, utilities and control > panels? Fix JOSM to drag with a single button mouse, and you should be golden. :) Regards, -- Christopher Schmidt MetaCarta ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] [OSM-dev] Polygons in OSM don't necessarily comply to simple feature specification
On Thu, Apr 17, 2008 at 12:15:16AM +0200, Frederik Ramm wrote: > Hi, > > > The only exceptions apparently > > being that self-intersecting polygons are allowed in OSM. > > The wiki page you cited says "In general, a 2D geometry is simple if > it contains no self-intersection." - what do they mean by "2D > geometry"? Specifically, would a self-intersecting *line* be allowed? > (I like to think of points as 0D, lines as 1D, and areas as 2D but I > have a feeling the GIS people might view this differently?) "Geometry in a 2 dimensional plane." In a 2 dimensional plane, all geometries are 2d, because you specify their coordinates in two dimensions. Regards, -- Christopher Schmidt MetaCarta ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] [OSM-dev] Polygons in OSM don't necessarily comply to simple feature specification
On Thu, Apr 17, 2008 at 12:19:19AM +0200, Iván Sánchez Ortega wrote: > El Miércoles, 16 de Abril de 2008, Christopher Schmidt escribió: > > On Wed, Apr 16, 2008 at 11:28:32PM +0200, Martijn van Exel wrote: > > > yesterday a colleague approached me asking why OSM data doesn't comply to > > > the Simple Feature specification[...] > > > > Is this something that is being considered? I guess it would be easy > > > to check for self-intersection upon adding / changing a polygon. > > > > "Easy"? I don't think that this is true... determining self-intersection > > is hard. > > IMHO, checking for self-intersection is as easy as the Simple Features > Specification is simple ;-) > > > Now, really, OSM data doesn't comply with OGC's Simple Features spec because > it doesn't need to in order to work. That's it. > > Even more - if OSM's API would support SFs, the number of geometries would > raise from 3 (nodes, ways, relations) to 6, increasing the complexity of > *any* tool that wants to work with the API. 7, really, since Simple Features doesn't describe relations, and OSM would still need them. > About importing into MS SQL server: Has your colleague browsed the subversion > repository? Namely, /applications/utils/export/ - I guess that osm2pgsql > could be hacked to work against MS SQL instead of Postgres. Or import into > postgres, dump the data into WTK, import into MS SQL. Probably not. PostGIS doesn't prevent self-intersecting polygons, so he would probably have the same problem taking the data from PostGIS -> SQL server. Regards, -- Christopher Schmidt MetaCarta ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] [OSM-dev] Polygons in OSM don't necessarily comply to simple feature specification
On Wed, Apr 16, 2008 at 11:58:21PM +0200, Martijn van Exel wrote: > Op 16 apr 2008, om 23:41 heeft Christopher Schmidt het volgende > geschreven: > >On Wed, Apr 16, 2008 at 11:28:32PM +0200, Martijn van Exel wrote: > >It seems likely that the netherlands 'self intersecting polygons' are > >simply the result of poorly curated coastline imports or something > >similar: in general, self-intersecting polygons aren't useful for > >anything I can think of in OSM, but preventing it is hard, and not > >really within the spirit of *most* simple geographic data tools. > > Why not? Simple Features to me seem to be all about the spirit of > simplicity - and they exclude self-intersection. But implementatons don't. (MS's spatial offering is somewhat lonely in respecting this.) In any case, OSM doesn't have polygons, so OSM can't prevent the intersection of Polygons. The fact that the interpretation of specific types of ways as polygons is common does not make the API have that property. Discourating this behavior, or preventing it, is therefore not an API level decision, but an editor-level decision. Regards, -- Christopher Schmidt MetaCarta ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] [OSM-dev] Polygons in OSM don't necessarily comply to simple feature specification
On Wed, Apr 16, 2008 at 11:28:32PM +0200, Martijn van Exel wrote: > Hi all, > > The only exceptions apparently being that self-intersecting polygons > are allowed in OSM. He found a couple hundred in the Netherlands' OSM > data. > > Is this something that is being considered? I guess it would be easy > to check for self-intersection upon adding / changing a polygon. "Easy"? I don't think that this is true... determining self-intersection is hard. Also, note that many many 'GIS' implementations also allow self-intersecting polygons. Shapefiles, GML, etc. etc. and the tools around them all 'allow' this insofar as there is typically no technological limitation preventing it. It seems likely that the netherlands 'self intersecting polygons' are simply the result of poorly curated coastline imports or something similar: in general, self-intersecting polygons aren't useful for anything I can think of in OSM, but preventing it is hard, and not really within the spirit of *most* simple geographic data tools. Regards, -- Christopher Schmidt MetaCarta ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Oh look, a scale bar. But...
On Wed, Apr 16, 2008 at 08:32:13PM +0200, Norbert Hoffmann wrote: > Dermot McNally wrote: > > >I became aware of the new scale bar on the slippy map through another > >thread over on dev. It's certainly nice to have one, and it was an > >obvious absence that google maps (and others) had but OSM didn't. > > Shouldn't a scale bar change its length, when scrolling the map > "vertically"? Read the dev thread. The basic answer is "Sure, as an option: take it to the OpenLayers mailing list if you want to implement it." Regards, -- Christopher Schmidt MetaCarta ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Oh look, a scale bar. But...
On Wed, Apr 16, 2008 at 07:01:01PM +0100, Dermot McNally wrote: > I did say it was a quick look. FWIW, this is the reference i found: > > http://trac.openlayers.org/wiki/Addins/ScaleBar > > And as I say, it's great to have one. The ScaleBar control is not the same as the control currently in use (Which is the ScaleLine control): ScaleBar is a supported addin that is not included in trunk. Regards, -- Christopher Schmidt MetaCarta ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Icelandic lights
On Fri, Apr 04, 2008 at 10:10:31PM +0100, OJ W wrote: > p.s. if you want to see that PDF file in JOSM: > > http://almien.co.uk/Misc/IcelandLights/ Curious about the outliers. Anyway, for people who like the web better (and want a preview of 2.6RC1): http://crschmidt.net/osm/iceland-lights.html This will be pretty slow in FF2, Faster in FF3, and faster in Safari (but won't work in Safari < 3). http://crschmidt.net/osm/iceland-lights.html?zoom=6&lat=63.78249&lon=-62.92969&layers=BT is kinda weird, for example. Regards, -- Christopher Schmidt MetaCarta ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] OSMXAPI and wget failing miserably
On Sat, Apr 05, 2008 at 03:52:37PM +1100, Matt White wrote: > Is anyone else having issues getting data from informationfreeway.org > using OSMXAPI? A scheduled dump I run has started failing all the time, > and a couple of manual extracts are returning nothing. I think my query > is right (certainly my scheduled dump ran nicely for many days). But I > know the daily diffs choked a couple of weeks ago. Have there been > changes made to extracting since then? Has this been happening since last weekend only? If so, then this is matching other reports I've been receiving. I only know how to keep the apache server up and running. When that is running fine, osmxapi fixes are beyond my skill level. I can't see anything obvious from the server logs that indicates what's wrong. The zappyds appear to be up, but I'm definitely not getting any data out. (There's also 16000 email messages from cron in etiennes mail folder from what looks like failed loading of minutely diffs.) All I can say is "Ask Etienne", and it seems as if he's unavailable to investigate at the moment. > Currently trying to extract the Washington DC area using: > > wget --timeout=0 > "http://www.informationfreeway.org/api/0.5/*[bbox=-77.4,39,-76.7,38.7]"; > -O WashingtonDC.osm > > which I think is correct. > > So, does anybody know what's going on? > > Matt > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk -- Christopher Schmidt MetaCarta ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Tah.openstreetmap.org/MapOf/ with georeferencing
On Sat, Apr 05, 2008 at 09:24:44AM +0800, maning sambale wrote: > > > > Wouldn't it be nice to have an option to get maps with georeferencing info > > from > > http://tah.openstreetmap.org/MapOf/? > > > > I have seen a working example of this. With an OSM image capture utility > > "OSM-Map" (http://alpo.hassinen.googlepages.com/osm-map) > > user can not only capture a map from screen to image file but also store > > the > > corresponding calibration file either in MapInfo .tab or OziExplorer .map > > format. Thus the captured images can be used in all GIS software or in > > OziExplorer. Some tweaking may be needed, for example gdal supports > > georeferencing with .tab files only for tiff images, and before using > > images > > in OziExplorer CE they must first be converted to special Ozi image format > > with another utility. However, often a georeferenced image is much more > > that just an image. > > Or save as jpg with a jgw georeferencing file. Code is in SVN. If you commit something, let me know, and I'll svn up. If you write a patch and can't commit, email the dev list the patch, then let me know (I skim, but tend to notice 'tah' in subjects), and I'll review it. Regards, -- Christopher Schmidt MetaCarta ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] OSM TIGER-based map quality
On Fri, Apr 04, 2008 at 10:53:43AM -0700, Dave Hansen wrote: > > On Fri, 2008-04-04 at 13:51 -0400, Christopher Schmidt wrote: > > On Fri, Apr 04, 2008 at 10:31:11AM -0700, Dave Hansen wrote: > > > On Fri, 2008-04-04 at 09:12 -0400, Christopher Schmidt wrote: > > > > That is exactly what I am suggesting, based on an examination of the > > > > objects in the area you're looking at: all of them have been updated > > > > several times (as the history URL above demonstrates) by a single user > > > > in what seems to clearly be a cleanup effort. (This was based on using > > > > an OpenLayers map to select 10 different streets based on the lonlat I > > > > observed in your JOSM instance and view the history for each.) > > > > > > If this is true, then we can probably go back and fix it. We have all > > > of the TIGER tlid (unique ids) for all of the uploaded data. Have those > > > remained the same in the new TIGER data? > > > > Fix... what? OSM is correct here... perhaps you mean "We can improve > > TIGER 2007 with OSM data"? > > Did I misunderstand what's going on? > > I assumed that the TIGER '07 data is better than the TIGER '05 (or so) > data that we populated OSM with. If it is better, we can update OSM > from TIGER '07. The images that were shared in this thread demonstrate that OSM is *way* better than TIGER '05 or '07. Regards, -- Christopher Schmidt MetaCarta ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] OSM TIGER-based map quality
On Fri, Apr 04, 2008 at 10:31:11AM -0700, Dave Hansen wrote: > On Fri, 2008-04-04 at 09:12 -0400, Christopher Schmidt wrote: > > That is exactly what I am suggesting, based on an examination of the > > objects in the area you're looking at: all of them have been updated > > several times (as the history URL above demonstrates) by a single user > > in what seems to clearly be a cleanup effort. (This was based on using > > an OpenLayers map to select 10 different streets based on the lonlat I > > observed in your JOSM instance and view the history for each.) > > If this is true, then we can probably go back and fix it. We have all > of the TIGER tlid (unique ids) for all of the uploaded data. Have those > remained the same in the new TIGER data? Fix... what? OSM is correct here... perhaps you mean "We can improve TIGER 2007 with OSM data"? Regards, -- Christopher Schmidt MetaCarta ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] OSM TIGER-based map quality
On Fri, Apr 04, 2008 at 01:53:24PM +0100, Jonathan W. Lowe wrote: > On Fri, 2008-04-04 at 07:05 -0400, Christopher Schmidt wrote: > > On Fri, Apr 04, 2008 at 08:29:56AM +, Jonathan W. Lowe wrote: > > > When overlaying OSM with the recently available TIGER 2007 shapefile > > > data for Census Blocks in Alameda County (California), I'm encountering > > > both an offset and difference in relative position of the linework. In > > > short, OSM's data looks a lot more accurate and consistent -- streets > > > that should be straight actually look straight in OSM, but often zig-zag > > > in the TIGER 2007 edges and tabblock shapefiles. For a visual, visit: > > > http://www.giswebsite.com/demos/tiger_overlays.html > > > > Um, isn't this the whole point of OSM? The TIGER data was imported so > > that it could be improved manually by users. This doesn't include just > > the geometry either: attributes have been changed as well. (See > > http://crschmidt.net/osm/history.html?type=way&id=21456366) > > Thanks, Chris -- are you suggesting that the TIGER 2007 reissue from the > US Census is not lining up with OSM in some (rather extensive) areas > because the geometry in those areas has been completely improved > manually since the upload of TIGER completed earlier this year. Yes, > obviously, such a major improvement in accuracy from manual attention is > one of the (many) wonderful benefits of OSM -- I guess I'm just > surprised that so much manual editing could have been accomplished for > such an extensive area given the short time TIGER has been available for > editing in OSM. Is there any existing interface for visualizing which > features have changed in OSM for a given area? That is exactly what I am suggesting, based on an examination of the objects in the area you're looking at: all of them have been updated several times (as the history URL above demonstrates) by a single user in what seems to clearly be a cleanup effort. (This was based on using an OpenLayers map to select 10 different streets based on the lonlat I observed in your JOSM instance and view the history for each.) > > > Any observations or ideas about where the misalignment might come from? > > > > This misalignment is common in TIGER: It's designed for 1:10 > > accuracy. Anything more than that (you're at about 1:7500 there) is not > > going to be accurate. (Or at least likely to not be.) > > I may not be communicating the scenario clearly enough -- TIGER > misalignment is common with other non-TIGER data certainly, but TIGER > data is not misaligned with other TIGER data of the same issue. I'm > encountering what I thought was the latter case. No: what you're encountering is TIGER misalignment with reality. OSM is much closer to reality in this instance than TIGER. > TIGER data models both visible physical features such as streets, but > also invisible census data collection boundaries such as blocks and > tracts. The block and tract boundaries and the street centerlines are > derived from the same single topologic source, so when viewed together, > line up perfectly unless one or the other has been altered independently > since original release. The 2007 shapefile issue confirms this -- > linestrings in the "edges" shapefile perfectly match the polygon > boundaries in the "tabblock" shapefile. But neither match the OSM > geometry, at least using the conversion and display methods I've used > within Berkeley's geographic extents. Right. Because TIGER is wrong :) > Since all the data has the same > parentage, I initially thought there would be a tighter match between > TIGER 2007 and OSM TIGER, but not if the editing to OSM TIGER has been > as extensive as you seem to be suggesting. That is correct. > > > Though it smells partially like a datum problem, that path hasn't > > > yielded any solutions yet. > > > > Doubtful. You'd have a more significant shift. > > Experimenting with NAD27 to NAD83 conversions actually produces a > similar shift, depending on the region. But I agree -- it seems to be > something else. Hm. I would have expected it to be more significant by a factor of about two, from observation, but I could be mis-guessing the scale here: I'm used to working in Cambridge, rather than SF. In any case, the misalignment is just a standard misalignment of TIGER data to reality: OSM is much closer to reality, despite the initial import being from TIGER. > > This is the real power of OSM at work. See it, and marvel in its glory. > > :) > Yes, marvelous it most certainly is. I currently use OSM (via an > OpenLayers client) w
Re: [OSM-talk] OSM TIGER-based map quality
On Fri, Apr 04, 2008 at 08:29:56AM +, Jonathan W. Lowe wrote: > When overlaying OSM with the recently available TIGER 2007 shapefile > data for Census Blocks in Alameda County (California), I'm encountering > both an offset and difference in relative position of the linework. In > short, OSM's data looks a lot more accurate and consistent -- streets > that should be straight actually look straight in OSM, but often zig-zag > in the TIGER 2007 edges and tabblock shapefiles. For a visual, visit: > http://www.giswebsite.com/demos/tiger_overlays.html Um, isn't this the whole point of OSM? The TIGER data was imported so that it could be improved manually by users. This doesn't include just the geometry either: attributes have been changed as well. (See http://crschmidt.net/osm/history.html?type=way&id=21456366) > Any observations or ideas about where the misalignment might come from? This misalignment is common in TIGER: It's designed for 1:10 accuracy. Anything more than that (you're at about 1:7500 there) is not going to be accurate. (Or at least likely to not be.) > Though it smells partially like a datum problem, that path hasn't > yielded any solutions yet. Doubtful. You'd have a more significant shift. This is the real power of OSM at work. See it, and marvel in its glory. :) Regards, -- Christopher Schmidt MetaCarta ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] OSMXapi error 501
On Thu, Apr 03, 2008 at 11:17:31AM +0800, maning sambale wrote: > Is the osmxapi working on the hourly diffs now? Minutely, so far as I can tell based on the way that the server behaves. Regards, -- Christopher Schmidt MetaCarta ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] OSMXapi error 501
On Sun, Mar 30, 2008 at 01:16:52PM +0100, 80n wrote: > One instance of osmxapi (zappy2) is affected by this, but the other instance > (zappy1) is running normally. However, apache is having problems and so > requests are not getting through to zappy1. This is now totally broken: I've emailed someone to go physically poke the machine. I will update again when this is done. I apologize for the inconvenience. Regards, -- Christopher Schmidt MetaCarta ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] OSMXapi error 501
On Sat, Mar 29, 2008 at 05:03:54PM +0100, J.D. Schmidt wrote: > Chris Hill skrev: > > I've been trying to extract data from OSMXapi. It seems to respond with > > ERROR 501 - Internal Server Error to each request. Is it broken? > > > > cheers, Chris > > Same server that runs [EMAIL PROTECTED] afair - and that server is down at > the moment. > Crschmidt posted the following on the [EMAIL PROTECTED] list : This shouldn't have affected osmxapi other than temporarily, but in any case, Hypercube is back in the saddle now, so if there is a continuing problem, it likely needs to be fixed by etienne: unfortunately, I don't know much about how to bring this back online. Regards, -- Christopher Schmidt MetaCarta ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Server speed
On Sat, Mar 01, 2008 at 07:39:06PM +, Chris Hill wrote: > The OsmaRender and Information Freeway slippy maps are *very* slow today. Is > there a problem? > cheers, Chris > There was; there shouldn't be anymore. Sorry about htat. Regards, -- Christopher Schmidt MetaCarta ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] rendering with mapnik, what do I need?
On Fri, Feb 29, 2008 at 10:21:04PM +, Gervase Markham wrote: > >>> 2. What do I need? PostgreSQL? Python? What else? > >> See http://wiki.openstreetmap.org/index.php/Mapnik > > It's rather short. Is it really that simple...? > > I'm surprised by that reaction... I just read the Mapnik page and > thought "that's flipping complicated". > > Mapnik itself, judging by http://www.mapnik.org/, seems to regard the > whole PosgreSQL thing as optional. Is there any way of getting OSM data > into a format Mapnik will render without having to set up a database? There is active ongoing development to support rendering with mapnik directly from a .osm file, I believe. Regards, -- Christopher Schmidt MetaCarta ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Landsat vs OpenAerial Landsat (in JOSM)
On Tue, Feb 26, 2008 at 11:28:30AM +0200, Lauri Hahne wrote: > I couldn't help noticing that that the Landsat images provided by > OpeanAerial map look muck worse than the Landsat images downloaded > directly from Nasa. You can see an example at > http://www.flickr.com/photos/[EMAIL PROTECTED]/2293670552/sizes/o/ the > upper image is from OpenAerial map and the lower one from Nasa. > > I wonder if Potlatch also suffers from this. Depends entirely on where you are. Since colorizing landsat imagery is a choice of algorithms, those algorithms work better in some areas, and worse in others. In my hometown, I prefer the i-Cubed Landsat over the NASA landsat, though clearly that's not appropriate in the area you were looking at. Regards, -- Christopher Schmidt MetaCarta ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Anything wrong with the slippymap Osmarender layer?
On Fri, Feb 15, 2008 at 06:14:37PM +0100, Igor Brejc wrote: > The slippymap does not show any Osmarender tiles, only Mapnik ones... The server is dead. I've sent off an email to have it restarted. Regards, -- Christopher Schmidt MetaCarta ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] map rectifier
On Tue, Jan 22, 2008 at 04:26:06PM +, Steve Chilton wrote: > Is the map rectifier working: > http://labs.metacarta.com/rectifier/ Nope. Regards, -- Christopher Schmidt MetaCarta ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Why place matters, slides from Vanessa Lawrence talk
On Fri, Jan 11, 2008 at 01:19:32PM +, Artem Pavlenko wrote: > Marking 'dirty' areas by processing planet diff sounds reasonable but > we only generate diffs weekly, afaik. > My understanding is that generating planet and planet diffs takes > very long time at the moment which brings us back to the eternal > quest of improving main DB. I'm not even suggesting to use postgresql :D Er, we do hourly diffs now, using osmosis. Regards, -- Christopher Schmidt MetaCarta ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] The OSM licence: where we are, where we're going
On Wed, Jan 09, 2008 at 04:16:59PM +, Longbow4u wrote: > It is not proven that CC-BY-SA does not work for maps. You're probably not on the legal-talk list, but if you're interested in discussing this further, I highly encourage you to join that list. There are a number of salient points being discussed there that might help change your understanding of the current legal situation. Regards, -- Christopher Schmidt MetaCarta ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Adding vmap0 road data to OSM
On Sun, Jan 06, 2008 at 12:27:25AM +, Bruce Cowan wrote: > > On Sat, 2008-01-05 at 12:48 -0500, Will Harrison wrote: > > > This would benefit the custom scenery project, since once all the > > vmap0 road data have been added to OSM the intent is to use OSM data > > for the scenery. But I think this could also be very helpful to the > > OSM project, as vmap0 contains data for the entire world and it would > > give OSM at least rough coverage of the entire globe. Is anyone > > interested in helping? > > I can see why you'd want to add vmap0 data in places that have no > mapping, but IMHO such bad data should not be added to OSM. > > I think having no roads in Flightgear in these areas would be better > than bad roads, saying as this bad data would have to be in OSM. I disagree. Many of the commercial providers use vmap0 as a 'backfill' for areas that are not well mapped via commercial means. In fact, some of the AND data that has been provided for China is exactly this: vmap0 data. The data is low resolution -- the map itself was only ever designed for 1:1M scale, and even then it's up to 30 years old, so there are some obvious problems with it for that case. Still, it's an obvious way for users to quickly get an idea that they may be able to contribute: in areas where there is no existing data, vmap0 can provide a reason for people to participate. I think that the important thing in this case is not "Do we import it or do we not import it" -- there's no reason that having low resolution data hurts OSM so long as it is properly labelled. Instead the question that I see is "How do we make sure that people understand the data is low resolution, and how do we make sure that we don't interfere with any existing data?" The answer to the latter seems relatively simple: limit vmap0 data imports to areas where there is no existing coverage nearby. "Nearby" is relative, but if you only import vmap0 data if there is no OSM data within, say, 100km, you're unlikely to bump into any active mapping going on (in my experience). You'd get a 'ring' around any hotspots that would be protected. I think that those of us in the US have discovered that even when TIGER is woefully incorrect -- it's easier to correct than it is to create anew. (I could be wrong on this, but I'm hoping others can back me up.) So long as vmap0 *doesn't hurt existing mapping*, and is properly tagged -- perhaps even such that it's not rendered in the main maps at all -- then I don't think OSM is hurt by having the data included. Regards, -- Christopher Schmidt MetaCarta ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Yahoo's imagery VS Google's imagery?
On Sun, Dec 30, 2007 at 02:55:01AM +, Yann wrote: > Hello, > > There was a guy from google at SOTM so I assume we did, but just to make > sure: did we actually asked google if we could use their imagery? It's just > so much better than the one yahoo provides... I've personally sent emails to the best contact addresses I could find for the following: * Google Maps * Microsoft Virtual Earth * Digital Globe * Several other providers gleaned from the maps copyright lines at the time Not a single one of them ever responded. (Not even with a no.) Keep in mind that Google Maps is not a single imagery source: instead, there are hundreds of different sources, each with slightly different permissions as to what they can and can't do. (This is why, for example, the road maps served at maps.google.com and the road maps served via the Google Maps API are different -- the former is a combination of NavTeq and TelaAtlas, the latter is TelaAtlas only -- or at least was for a time.) It is unlikely that *all* of the imagery providers would accept reuse of their imagery for OSM's purposes, and probably similarly unlikely that Google would be able to set up a secondary worldwide satellite map cache with data that they could share. So there are unique problems in that case that Yahoo *doesn't* have -- using only a single imagery provider (combined with free data in many cases in the US). Additionally, comments from Google Maps team members have indicated to me that there are likely only two answers you would ever get out of Google Legal: "No", or no answer at all. (Which is clearly not the same thing as yes!) Regards, -- Christopher Schmidt MetaCarta ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
