Reconsider this project about editor-layer-index HOT 5 CLOSED

Using GitHub allows for discussion and verification about a change to a data source. Something that the wiki style does not provide.

This repo is also much simpler, not relying on a mysterious backend system scraping a wiki.

I asked about JOSM using this repo and you declined, so we moved on. iD and Vespucci use this index and I'm happy to help get other editors using it, too.

from editor-layer-index.

Sure I did not accept your proposal at that time. You asked to replace a working infrastructure with something new not yet working. What did you expect?

Before writing this comment I checked the tasks of this project a bit and too often found tasks essentially meaning "update to what JOSM did". Also there are troubles in these files, which JOSM's data has already fixed.

Regarding iD. The files in iD repository aren't equal to the ones here, so how can you state it is used?

This repo is also much simpler, not relying on a mysterious backend system scraping a wiki.

We have no mysterious backend scraping a Wiki. Maybe before talking about such things you at least should have a look at it. Maybe also learn a bit about Trac and the functionality it provides. It's only that the source code of the server interface is not open source, but only available to admins to reduce the risk of an attack in case of security issues in the server code. It seems you didn't even try to understand what exists before you started a new system?

That this repo is simpler is untrue: This page is a nice overview of what JOSM supports: http://josm.openstreetmap.de/wiki/Maps. I didn't find anything similar here. It's rather hard to understand the structure.

Using GitHub allows for discussion and verification about a change to a data source. Something that the wiki style does not provide.

That's a matter of policy and not technical. We had not a single case of vandalism, so there is no need to step back from permissions to freely modify.

But it seems here the situation is the same like it has been for Potlatch and Merkaartor. The unification approach means "Use what we designed". Sorry, but to do so it needs to be better and this isn't the case. I had a look at this for approx. one year and situation did not change.

Sorry that I asked. Feel free to continue as you want, inbeetween we can live without unification as our users are willing to improve the template sources when necessary. My comment "I don't believe a joined maps source place will work" again is true. This place supports one of the major three. Not much.

from editor-layer-index.

Unhelpful personal jabs aside, your objections to this project seem to boil down to two points:

1. It doesn't perform "validation checks": What do you mean by "validation"? If you mean that the XML is well-formed, the build process that generates the output files in this repo will already create valid XML and JSON. If you mean that it checks to make sure the listed endpoints are still responsive, you're right: we don't do that.
2. It's not what JOSM designed: I guess we just have different opinions about better design. It makes more sense to me that a list of imagery sources like this repo and JOSM's should be stored in a versioned repository of individual files where changes can be discussed and improved upon more easily than in a long wiki page on a Trac website.

Your point about ease of contribution stands: although we haven't had problems with people submitting sources, we should make it easier for less technical people. Although we do have a document about contributing, it could probably be more explicit.

We also could periodically check that sources are still returning valid responses and flag those that aren't.

from editor-layer-index.

Hi @stoecker, thanks for sharing your perspective. I do recognize that adding another imagery database rather than using one that already exists exacerbates the problem in some ways. However, none of the existing sources satisfied the requirement we wanted, that imagery sources could be versioned in individual files, and secondarily that they use JSON as the primary format. For maintenance, discussion, and ease of consumption, this is important.

I don't believe there is a conflict between "source-code based" and "community based". This may have been true 5 or 10 years ago, but the barriers to contribution are significantly lower now, and I anticipate that web-based collaboration backed by DVCS will continue to get easier and more widespread.

iD does use this imagery index. In fact, because tool support for git repositories is so widespread, it is very easy to add editor-imagery-index as an npm dependency of iD. This means we have automated imagery updates to iD without the need for any server infrastructure of our own.

from editor-layer-index.

I didn't want to comment here anymore, because actually I don't like the way Ian reacts. Nevertheless I want to give you an last answer. This project was started as an unification of editor imagery. It does not reach that goal. There is no communication back to JOSM, no requests for collaboration, nothing alike in a way of working together. For me it is a take JOSM's data and create something else (which is fine by the license).

Your basic requirements of JSON and ... make combined maintenance hard. You simply directly require what you want to use for iD. I have no problem with this, but please not under the goal of unification: This project has, beside the easy integration into a git repository, no advantage over what was there before (the JOSM maps wiki) - most of the imagery shapes have been created by the users of exactly that system.

The JOSM maps wiki also would allow access control. We choose not to enforce it and until now this was correct (beside the fact that nobody except admins can modify defaults). Discussion and issue tracking can and has been done in the JOSM trac. But because of the free edit it is not enforced. Version history is tracked as well.
We don't use individual source files for each source, but currently source groups based on countries. The infrastructure supports everything from big blob to single entry. Current country-based model is a fine working middle setup.

As said doing a JSON or GeoJSON export or even git push request is a small task (even as single files :-). We already do other similar automated tasks for i18n. Currently the server-side code is not openly available, but that's mainly a security issue than a policy. It's simply a bit more complicated to find a security hole and usually shows in the server logs, when you don't have the code - and nobody except the admins really needs access to this code.

I'm still open for collaboration as I was with Merkaartor and Potlatch. We changed and adapted our dataformats to be compatible to this or that, but never there was any real progress. If there is still interest contact me by mail.

P.S. I don't believe a DVCS based approach can reach many outside the developers world. Tell me, when you have the first example proving me wrong.

from editor-layer-index.