On 15/10/12 23:40, Alex Barth wrote:
- Translations are a frequent bottleneck for copy changes, unclear how to solve this.
I'm not sure why you think this, but I can only think it is because you are overthinking the issue and aiming for a level of perfection that we are never likely to achieve.
The way it works is this - you don't worry about translations as such at all. You just make sure strings are translatable and we commit that and then the translators get to work. Yes, when something new launches it will take a while to get translated, but that is something we live with as a volunteer project and it had worked perfectly well up to now.
- How could the Mapnik style be more open to improvements? We definitely need to get it on GitHub.
I'm happy to move this from svn to git but I'd like the team that look after it to buy into that first.
One of the problems here is that the person that leads this effort is primarily a cartographer rather than a developer, and is also on Windows which tends to lead to various technology issues.
I believe I'm right in saying that he doesn't have a working test setup at the moment since we moved to mapnik 2 and we need to sort that out but equally moving to git may be an issue because I believe Windows support in git is a bit patchy.
## Getting data out of osm.org - Starting from osm.org it could be more straightforward to find proper download options - Export tab on osm.org is one of the most popular locations, but needs a lot of improvement. E.g. it does not explain how the downloaded data can be used. How can export be more actionable? - There is an expectation problem around data downloads from osm - why exactly would a user download from the export tab, what are they looking for? why is embedding under exporting? if an export fails due to its size, it's not clear where to go to get a larger dump. - Should SVG export be replaced with something else, or improved in Mapnik enough to be worthwhile? - How can third party services like geofabrik's shapefile exports (or jXAPI) be tied in better? - (not a data export topic but came up here) there are needs around managing/merging external vector datasources, there's work around that in potlatch.
Exporting raw data was never the primary purpose of the export tab - it was really added to address the constant request for the ability to export images of an area.
The data export things was something I threw in because I could, and for most purposes people should be looking elsewhere for raw data.
Tom -- Tom Hughes ([email protected]) http://compton.nu/ _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev
