[OSM-dev-fr] [veille] Canal TP libère du code pour OpenStreetMap
Canal TP libère du code pour OpenStreetMap http://www.canaltp.fr/non-classe/canal-tp-libere-du-code-pour-openstreetmap/ -- Cyrille. ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
[Potlatch-dev] P2, snapshot-server, imports, vector layers and more
I've been working on methods of using external datasources as background vector layers in P2 and JOSM and have come up against a few issues. Background: P2 has excellent support for data layers but their full power is not exposed to the user by default. I am contemplating using snapshot-server with some extremely large datasets to make the data available to people using P2 and JOSM as vector layers. There are a few issues, but two that are relevant to P2 1. Data interchange formats. The standard format for interchanging .osm files suitable for importing is with negative object IDs and visible=true on each object (e.g. https://github.com/pnorman/ogr2osm/blob/master/testfiles/test1.xml). There is no changeset, version or user information on the objects. Both JOSM and P2 can read these. snapshot-server returns data in the same format as the API but with an additional attribute indicating if the object has been reviewed. The additional attribute prevents the files from working in JOSM but the bigger issue is the use of positive IDs. When an object is merged in JOSM it carries over its ID if it's a positive ID. This would lead to conflicts with existing data in the API. Even if JOSM were patched to allow it to work with these files and special-case their positive IDs, using positive IDs seems like a recipe for disaster, particularly when a standardized format exists. I must admit I have not verified if this would require changes to P2. It's possible that P2 would work fine if snapshot-server returned negative IDs. 2. Data layer exposure. To add a snapshot-server data layer to P2 you have to deploy your own P2 instance. This severely limits exposure. What makes it worse is that if I offer a data layer and deploy P2 and someone else does the same, you can't use both at the same time. A way to add a snapshot-server layer by pointing it at a configuration file (e.g. a json file) would be very useful. Better yet would also be a way to reveal data layers like imagery layers are, based on bbox (or better yet, by polygon). Not having any Flash or rails coding experience I can't help with the coding, so I figured my best option would to be to bring it to the list. A third issue is the relative lack of documentation on how to use vector layers in P2 but I expect that would improve with increased availability. ___ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev
Re: [osmosis-dev] Invalid actions during replication
Hi Paweł, On 11 November 2012 21:24, Paweł Paprota ppa...@fastmail.fm wrote: Hi all, On Friday I have implemented a simple validation in the OWL plugin that checks whether given entity action (create/modify/delete) can be applied to the current database state. See implementation: [1]. By invalid action I mean a situation when there is a delete action in the pipeline but there is no entity in the database to delete. Or modify action with version X when there is no version X - 1 in the database but some other version. I've been running replication for over a day now (in LOG mode, on a database with planet imported) and results are quite interesting. There is more invalid actions reported than I thought there would be. Some random examples: INFO: Invalid action: Node 1342627235 - Trying to modify entity that does not exist! INFO: Invalid action: Node 964649444 - Trying to modify entity that does not exist! INFO: Invalid action: Way 11133255 - Trying to modify entity that does not exist! INFO: Invalid action: Way 9105159 - Trying to modify entity that does not exist! I have not yet analyzed closely those entities that are reported but in general there should be no invalid actions at all on a full planet database with correct replication setup, am I correct in this assumption? It's possible that there could be errors during initial replication, but I would have thought they'd disappear eventually. It seems a bit odd. Unfortunately you will need to look into some examples one at a time to try to trace the source of the issue. It can be tedious to get to the bottom of replication problems. The pgsnapshot replication functionality has been around for a long time now and has been fairly reliable, but perhaps there's an issue in there somewhere. Also, if anyone's interested, this functionality would be trivial to port over to the pgsnapshot Osmosis plugin (--write-pgsql-change) since the OWL plugin is built from that plugin. I can do this if you think it could be useful. [1] https://github.com/ppawel/**osmosis/blob/owldb-plugin/** owldb/src/main/java/org/**openstreetmap/osmosis/owldb/** v0_6/impl/ChangeWriter.java#**L256https://github.com/ppawel/osmosis/blob/owldb-plugin/owldb/src/main/java/org/openstreetmap/osmosis/owldb/v0_6/impl/ChangeWriter.java#L256 Implementation notes: basically there is a invalidActionsMode paramater for the --write-owldb-change task (which is derived from --write-pgsql-change but with OWL-specific additions) that can be IGNORE (does nothing), LOG (logs information about the action) or BREAK (stops processing when invalid action occurs). I don't mind something like this being added, but I'd like to understand the source of your current issues first. If it turns out that it's normal behaviour and can't be fixed then there's not much point raising warnings. On the other hand, if there is a real issue here then it will be valuable. Brett ___ osmosis-dev mailing list osmosis-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/osmosis-dev
Re: [osmosis-dev] Single node ways
On 14 Nov 2012, at 11:48, Paweł Paprota ppa...@fastmail.fm wrote: On 11/14/2012 12:33 PM, Brett Henderson wrote: It sounds good to me. Osmosis typically tries to maintain data accuracy with no surprises, so I'm not particularly happy with the current situation of dropping ways even if they are invalid. Jochen Topf was the one who originally introduced the checks in WayGeometryBuilder to ensure a Way contained at least two nodes. He might have some thoughts on whether we can remove the checks. Perhaps it was simply introduced to avoid the additional overheads of having to do st_isvalid() checks? Based on my experience with processing geometry for OSM objects I'd strongly discourage having any invalid geometries in the database. This leads to very unpleasant surprises with ST_Union, ST_Intersection and other spatial functions. Upgrading the GEOS library (which PostGIS uses) helps a bit but still many operations can behave very strangely and after hours/days of debugging you find yourself hitting the invalid geometry wall. Whether Osmosis should be responsible for maintaining valid geometries is kind of a different question I think - depends on policy. But whatever you decide, it needs to be communicated front and center in documentation what geometry is created. The problem is that if you are using Osmosis to shunt the data into a database that you use to find and highlight these invalid geometries for the community to go and fix in the source data. I think that Osmosis could have a filter to drop invalid data, or even the inverse of only outputting the invalid data. Shaun ___ osmosis-dev mailing list osmosis-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/osmosis-dev
Re: [OSM-dev] Status of the Mapnik stylesheets
There is anyway an issue with the current Trac instance : source: subversion/applications/rendering/mapnik/osm.xml @ 28049 HTML preview not available, since the file size exceeds 102400 bytes. Could somebody increase this limit to 200-300K ? According to the wiki it's in /var/lib/trac/conf/trac.ini on Shenron. [mimeviewer] max_preview_size = 30 Yves 2012/11/14 Kai Krueger kakrue...@gmail.com Tom MacWright wrote The biggest problem with the Mapnik stylesheet right now is that it's in SVN. Not the technology, but the fact that this gives people without commit access to that repository no clear way to contribute. There is no way to 'just do it' until the style is actually maintained in GitHub, actually welcomes contributions, and has active maintainers. Until then we're just talking. I though SVN actually worked better than github for projects that don't have a maintainer. The SVN repository used to have a very inclusive account policy. I.e. basically anyone could get an account and then commit to any part of the repository. So people could just do it and commit their patches to the master branch of a project even if there was no clear or active maintainer. So people didn't even have to wait for someone to pull their patch into the maintainers repository. Whether those changes would then actually get deployed to the OSMF tileserver is another matter, but that is the same issue with any github repository too. But yes, I agree that currently the lack of a maintainer for the osm mapnik style sheet is probably the main problem. Kai -- View this message in context: http://gis.19327.n5.nabble.com/Status-of-the-Mapnik-stylesheets-tp5735606p5735694.html Sent from the Developer Discussion mailing list archive at Nabble.com. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] Status of osm2pgsql for Windows
Kai Krueger wrote: Dane Springmeyer wrote I'm sorry about not providing Windows binaries yet for Mapnik 2.x. The holdup is that I have a dev environment working that is running Visual Studio 2010, and I need to get a parallel setup running Visual Studio 2008 for support compiling the python bindings. Its a silly blocker, but will take time which I've yet to carve out. Last time you mentioned that one thing holding up compiling a new version of osm2pgsql for Windows was its use of C99. I think I have now ported it back to ansi C. Could you give compiling osm2pgsql another go at some point and let me know what else needs fixing to get it to work on Windows? Some time ago there was this announcement in this mailing list Peter Körner has built and uploaded a recent version (0.80.0 32bit id space) of osm2pgsql to http://osm4windows.org/downloads/ I have tried that version with Windows Vista 32-bit and it works. It takes much less memory than the year 2010 build, it reads .pbf format and it is faster (about 2 hours with finland.osm.pbf now vs. two and a half hours with finland.osm.bz2 with the previous). GDAL is still faster with my weak machine with dual core 1.2 GHz processor and 2 GB of memory and does the import into PosGIS in 30 minutes. Import into Spatialite takes only 10 minutes. Numbers are not exact because in my test osm2pgsql and GDAL schemas were not identical. -Jukka Rahkonen- ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Status of the Mapnik stylesheets
Hi, On 11/13/2012 11:36 PM, Tom MacWright wrote: There is no way to 'just do it' until the style is actually maintained in GitHub, actually welcomes contributions, and has active maintainers. Point 3 (active maintainers) is undoubtedly true. Point 2 (welcome contributions) is slightly difficult with the style as we do expect a certain amount of cartographic consistency. The Mapnik style is not something where people can scratch their personal itch by adding an icon or dash pattern for whatever they want rendered and then believe it will be added just like that; they ought to talk to the maintainers (see point 3) before. - This sounds rather obvious; you wouldn't change the design of a software package maintained by someone else and not talk to them before. But because it is so easy to e.g. add an icon, people are tempted to just fire off a patch and this later turns out to be a waste of time because it doesn't fit the overall concept. So yes, welcome contributions, but maybe one should have a so you want to contribute to the style document that suggests certain processes. Point 1 is purely a matter of taste; people are just doing it with trac as well (and suffering from 2/3 there too). Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Status of the Mapnik stylesheets
On 11/14/2012 12:04 PM, Frederik Ramm wrote: Point 1 is purely a matter of taste; people are just doing it with trac as well (and suffering from 2/3 there too). Surely you cannot deny the fact that Github has extremely positive effects on development? Why Trac has nowhere near such an effect I couldn't say but it is just the truth that once you put something on Github, people are *much* more likely to contribute. With open source projects nowadays, having something in SVN and Trac is like putting it in the basement and waiting until someone asks to see your basement... Paweł ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Status of the Mapnik stylesheets
Hi, On 11/14/2012 12:57 PM, Paweł Paprota wrote: With open source projects nowadays, having something in SVN and Trac is like putting it in the basement and waiting until someone asks to see your basement... This particular basement seems to have been visited at least 400 times without us doing something about it, so I think lack of interest is the least of our problems ;) I fully agree that GitHub is popular, but it is a pet peeve of mine to point out that alternatives exist, just like other people will complain if an Open Source project runs its mailing list on Google or so. With GitHub in the hands of a commercial company I fear that before too long they'll do something stupid to monetize the user base; this has happened countless times before. As the old adage goes, if you're not paying for the product then you are the product. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Status of the Mapnik stylesheets
Hi all, On 14/11/12 12:57, Paweł Paprota wrote: Surely you cannot deny the fact that Github has extremely positive effects on development? I don't see the point in discussing SVN/Trac vs. Git/GitHub as both systems are already in place. :-) The problem I see is that both systems are unmaintained. Cheers, Simon ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Status of the Mapnik stylesheets
On 11/14/2012 01:09 PM, Frederik Ramm wrote: I fully agree that GitHub is popular, but it is a pet peeve of mine to point out that alternatives exist, just like other people will complain if an Open Source project runs its mailing list on Google or so. With GitHub in the hands of a commercial company I fear that before too long they'll do something stupid to monetize the user base; this has happened countless times before. As the old adage goes, if you're not paying for the product then you are the product. I agree it's not ideal to use a closed and commercial solution for such an important thing like development and issue tracking. I believe the way OSM does it currently is the correct one - maintain own Git repos plus mirror them on Github. So I guess the main question is about issue tracking and maintainer support - here there is no easy way to mirror stuff... Paweł ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Status of the Mapnik stylesheets
On 11/14/2012 01:10 PM, Simon Legner wrote: Hi all, On 14/11/12 12:57, Paweł Paprota wrote: Surely you cannot deny the fact that Github has extremely positive effects on development? I don't see the point in discussing SVN/Trac vs. Git/GitHub as both systems are already in place. :-) The problem I see is that both systems are unmaintained. Agreed - I should have been more clear that by putting something on Github I don't only mean creating an account and setting up a Git/SVN mirroring but also supporting contributors, tracking issues/pull requests there etc. And that of course circles back to what you said about maintainership... Paweł ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Status of the Mapnik stylesheets
Matt Amos wrote: i'd sound a note of caution about having separate clean and detailed styles. we sort-of did that before with mapnik and osmarender respectively and... well, we don't have osmarender any more. That was a technology failure, though, rather than anything wrong with the concept itself. In principle, there are clear, identifiable, distinct needs for a showcase style and a debugging view. We want the great unwashed to look at OSM and say wow, that's a complete, accurate map; and we want our mappers to enjoy the gratification of seeing their changes rendered, because that's a powerful incentive to keep contributing. (I use the word view rather than style because it's conceivable that the latter could be provided some other way than a traditional Mapnik stylesheet, perhaps something along the lines of Kothic-JS.) So the problems we have right now are: - we don't have a debugging view, and that leads to inappropriate pressure on the showcase style (e.g. the 8,000 tints for subtly different forms of landuse) - the showcase style is temporarily stalled due to technological issues and both need fixing sooner rather than later. (For the showcase style, personally I think XML vs CSS is more of a problem than svn vs git, but that's an implementation detail.) cheers Richard -- View this message in context: http://gis.19327.n5.nabble.com/Status-of-the-Mapnik-stylesheets-tp5735606p5735775.html Sent from the Developer Discussion mailing list archive at Nabble.com. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Status of the Mapnik stylesheets
On Wed, 14 Nov 2012, Frederik Ramm wrote: I fully agree that GitHub is popular, but it is a pet peeve of mine to point out that alternatives exist, just like other people will complain if an Open Source project runs its mailing list on Google or so. With GitHub in the hands of a commercial company I fear that before too long they'll do something stupid to monetize the user base; this has happened countless times before. As the old adage goes, if you're not paying for the product then you are the product. Lots of people *are* paying for it though. I certainly am. cheers, Derick ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Status of the Mapnik stylesheets
On Nov 14, 2012, at 3:57 AM, Paweł Paprota wrote: On 11/14/2012 12:04 PM, Frederik Ramm wrote: Point 1 is purely a matter of taste; people are just doing it with trac as well (and suffering from 2/3 there too). Surely you cannot deny the fact that Github has extremely positive effects on development? Why Trac has nowhere near such an effect I couldn't say but it is just the truth that once you put something on Github, people are *much* more likely to contribute. [citation needed] With open source projects nowadays, having something in SVN and Trac is like putting it in the basement and waiting until someone asks to see your basement... Github is undoubtedly awesome, but as you said elsewhere in this thread the real need is also supporting contributors, tracking issues/pull requests there etc., human needs that extend from community support rather than choice of technology platform. I imagine that if a proper study was done comparing Github at its current age to other systems at four years of development, there would be a similar proportion of abandoned or ignored projects on all of them. Github is new enough to benefit from the Hawthorne Effect, and maybe moving the OSM.xml stylesheet there would allow it to bask in some of that glow for a period of time. The stylesheet is also an organically-grown system, and as Frederik pointed out it's not a good idea to just accept pull requests willy-nilly from anyone who wants to see their pet tag rendered. Not to mention the ease with which a punishing, unsustainable Postgres query might be introduced, or potential inconsistencies in osm2pgsql style column mappings across systems. -mike. michal migurski- contact info and pgp key: sf/cahttp://mike.teczno.com/contact.html ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Status of the Mapnik stylesheets
On Wed, Nov 14, 2012 at 8:23 PM, Richard Fairhurst rich...@systemed.netwrote: - we don't have a debugging view, and that leads to inappropriate pressure on the showcase style (e.g. the 8,000 tints for subtly different forms of landuse) Actually we do, and that's the data layer. Unfortunately, I think there's a perception that the data layer doesn't provide the gratification that mappers want. Or maybe we just need to highlight this layer more. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Status of the Mapnik stylesheets
On 14/11/2012 16:34, Eugene Alvin Villar wrote: Unfortunately, I think there's a perception that the data layer doesn't provide the gratification that mappers want. Absolutely, and it never well. The data layer looks less like a map than the MapCSS renderings in Potlatch and JOSM do. It's no substitute. cheers Richard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Status of the Mapnik stylesheets
On 11/14/2012 05:34 PM, Michal Migurski wrote: Why Trac has nowhere near such an effect I couldn't say but it is just the truth that once you put something on Github, people are *much* more likely to contribute. [citation needed] My statement was based on my own experience with open source projects. I cannot be bothered to find some hard evidence that Github makes people much likely to contribute though, it's just a fact. :-) The stylesheet is also an organically-grown system, and as Frederik pointed out it's not a good idea to just accept pull requests willy-nilly from anyone who wants to see their pet tag rendered. Not to mention the ease with which a punishing, unsustainable Postgres query might be introduced, or potential inconsistencies in osm2pgsql style column mappings across systems. Sure, the same is true for any software project really... accepting everything is not a good idea as it leads very quickly to feature creep and unmaintainable code base. However, this is getting a bit off-topic. I concede the point that Github vs Trac is not the most important discussion in the world while there's no activity with current 400+ issues. Not sure to whom I'm addressing this statement but... I'm involved in a number of OSM related things at the moment but if there is anything I could do to help with the current Mapnik/style situation then don't hesitate to contact me privately. I can do what I can to help with anything except for the esthetic aspects as I'm no artist :-) BTW, it feels like more and more people are asking about the main style development, hopefully some kind of critical mass is building and things will move forward soon. Paweł ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Status of the Mapnik stylesheets
Le mercredi 14 novembre 2012 17:34:17, Eugene Alvin Villar a écrit : Actually we do, and that's the data layer. Unfortunately, I think there's a perception that the data layer doesn't provide the gratification that mappers want. Or maybe we just need to highlight this layer more. IMHO Your forgot an important feature mappers want : Have I done a mistake or not ? Even if we keep on telling them : don't map for the renderer (in the new sense it has become) they still want to know if what they've done is correct (correct in a non so obvious sense where answers is it in the wiki It's always correct because you can tag how you want are not what they expect) +the data layers isn't available as a JOSM slippy map selector (and the plugin download as you pan and zoom isn't as functional because it can hardly work on low zooms) -- sly (sylvain letuffe) ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Status of the Mapnik stylesheets
Lennard l...@xs4all.nl wrote: This requires a reload of the database to at least get public_transport=* in. To get a little bit more flexibility which such stuff we now use hstore and views on the german-style tileserver. The overhead is acceptable when using --hstore-match-only Our views ans the osm2pgsql style-file is compatible with the standard mapnik style and available here: http://svn.openstreetmap.org/applications/rendering/mapnik-german/views/ Regards Sven -- Thinking of using NT for your critical apps? Isn't there enough suffering in the world? (Advertisement of Sun Microsystems in Wall Street Journal) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Status of the Mapnik stylesheets
On 14/11/12 17:53, Paweł Paprota wrote: I cannot be bothered to find some hard evidence that Github makes people much likely to contribute though, it's just a fact. :-) Thats not the problem, people being likely to contribute! It's maintenance. Stop this github makes everything better insanity, really ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [josm-dev] Adding your own imagery
kristy van putten writes: This is my first time on this list, so apologies if I am asking the same question as someone else. I have a team of GIS people digitising in OpenStreetMap and we have found that there is no imagery for a section of the area we really need to digitise. I have got imagery from a LiDAR survey that we (Australian Government) has full IP rights to. The format of the imagery is ECW. It's been a day since you asked this question, and nobody has responded. I suspect that's because of the image file format. I'm pretty sure that it's a proprietary image format. According to this Wiki page: http://en.wikipedia.org/wiki/ECW_%28file_format%29 , there's an SDK which is open source. It's likely to be possible to use that SDK to convert the images into bigger files in a more standard file format. Or ... use the SDK to add support to MapProxy so it can read the files and re-encode in a more generally usable file format. -- --my blog is athttp://blog.russnelson.com Crynwr supports open source software 521 Pleasant Valley Rd. | +1 315-600-8815 Potsdam, NY 13676-3213 | Sheepdog ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Adding your own imagery
From: Russ Nelson [mailto:nel...@crynwr.com] Sent: Wednesday, November 14, 2012 6:32 PM To: kristy van putten Cc: josm-dev@openstreetmap.org Subject: Re: [josm-dev] Adding your own imagery kristy van putten writes: This is my first time on this list, so apologies if I am asking the same question as someone else. I have a team of GIS people digitising in OpenStreetMap and we have found that there is no imagery for a section of the area we really need to digitise. I have got imagery from a LiDAR survey that we (Australian Government) has full IP rights to. The format of the imagery is ECW. It's been a day since you asked this question, and nobody has responded. I suspect that's because of the image file format. I'm pretty sure that it's a proprietary image format. According to this Wiki page: http://en.wikipedia.org/wiki/ECW_%28file_format%29 , there's an SDK which is open source. It's likely to be possible to use that SDK to convert the images into bigger files in a more standard file format. Or ... use the SDK to add support to MapProxy so it can read the files and re-encode in a more generally usable file format. gdal can read .ecw and through it mapserver, and through it mapproxy can serve it. It could also convert .ecw to geotiff or some other more common format. All the options for dealing with a large imagery involve setting up a server to host it. If you're able to grant the necessary permissions you might be able to get someone in the community to host it. I know Grant Slater hosts AGRI imagery for Australia. ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Adding your own imagery
HI, Thank you very much for everyones help, I was able to take simon advice and convert the ecw file to jpeg with a worldfile and import it in using the importimageplugin. I did have to up the JOSM memory to do this, following the instructions on http://wiki.openstreetmap.org/wiki/JOSM/Mac Thanks to Simon, Paul and Russ in replying to me! Cheers On 15 November 2012 11:18, Paul Norman penor...@mac.com wrote: From: Russ Nelson [mailto:nel...@crynwr.com] Sent: Wednesday, November 14, 2012 6:32 PM To: kristy van putten Cc: josm-dev@openstreetmap.org Subject: Re: [josm-dev] Adding your own imagery kristy van putten writes: This is my first time on this list, so apologies if I am asking the same question as someone else. I have a team of GIS people digitising in OpenStreetMap and we have found that there is no imagery for a section of the area we really need to digitise. I have got imagery from a LiDAR survey that we (Australian Government) has full IP rights to. The format of the imagery is ECW. It's been a day since you asked this question, and nobody has responded. I suspect that's because of the image file format. I'm pretty sure that it's a proprietary image format. According to this Wiki page: http://en.wikipedia.org/wiki/ECW_%28file_format%29 , there's an SDK which is open source. It's likely to be possible to use that SDK to convert the images into bigger files in a more standard file format. Or ... use the SDK to add support to MapProxy so it can read the files and re-encode in a more generally usable file format. gdal can read .ecw and through it mapserver, and through it mapproxy can serve it. It could also convert .ecw to geotiff or some other more common format. All the options for dealing with a large imagery involve setting up a server to host it. If you're able to grant the necessary permissions you might be able to get someone in the community to host it. I know Grant Slater hosts AGRI imagery for Australia. -- *Kristy Van Putten* Spatial Analyst, Data Manager | AIFDR** Mb: +62 811 987 573 ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
