Opened 7 years ago
Last modified 7 years ago
#16226 new enhancement
Integrate osm-community-index
Reported by: | joostschouppe | Owned by: | team |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | Plugin | Version: | |
Keywords: | community | Cc: |
Description
The osm-community-index https://github.com/osmlab/osm-community-index contains many channels to get in touch with local mappers. The implementation in ID is already driving more people to those channels. It would be nice if JOSM mappers are also shown these channels somehow. The structure of the community data is almost identical to the mapping layer index, which is already implemented in JOSM. So it might be relatively easy.
(sorry if this has been posted already or this is the wrong place)
Attachments (0)
Change History (7)
comment:1 by , 7 years ago
Component: | unspecified → Plugin |
---|
comment:2 by , 7 years ago
Replying to joost.schouppe@…:
the mapping layer index, which is already implemented in JOSM
To get the facts right: ELI was created long after JOSM map index.
follow-up: 5 comment:3 by , 7 years ago
So, if not a task for the core, who's task is it then ? The influx of mappers that start communicating with the local community due to this implemented into ID is very noticable. It would benefit OSM as a whole a lot. Now where do we direct our request to ?
follow-up: 6 comment:4 by , 7 years ago
@Don-vip, I'm nut sure which fact you are trying to set straight. I just mentioned the Editor-layer-index (ELI) as I understand it is available within JOSM, and that the community index follows the same kind of logic; hence an implementation might borrow some code from there.
@stoecker: this is something you want to show most of all to relative beginners, or to people who aren't naturally inclined to check documentation. So IMHO it would defeat the purpose to implement this as a Plugin
comment:5 by , 7 years ago
Replying to glenn@…:
So, if not a task for the core, who's task is it then ? The influx of mappers that start communicating with the local community due to this implemented into ID is very noticable. It would benefit OSM as a whole a lot. Now where do we direct our request to ?
Whoever finds the time and motivation to write a plugin.
comment:6 by , 7 years ago
Replying to joost.schouppe@…:
@Don-vip, I'm nut sure which fact you are trying to set straight. I just mentioned the Editor-layer-index (ELI) as I understand it is available within JOSM, and that the community index follows the same kind of logic; hence an implementation might borrow some code from there.
ELI is not available within JOSM. ELI is a clone of the JOSM concept.
@stoecker: this is something you want to show most of all to relative beginners, or to people who aren't naturally inclined to check documentation. So IMHO it would defeat the purpose to implement this as a Plugin
JOSM is an editor and no multi-purpose communication plattform. There are already communication channels in JOSM. This here is way too much for the core.
comment:7 by , 7 years ago
JOSM is an editor and no multi-purpose communication plattform. There are already communication channels in JOSM. This here is way too much for the core.
Editors are the one place everyone goes to. OSM documentation and tools are notoriously diverse and spread out. In the case of tags, this is largely solved with presets. In the case of "how to get in touch with local communities" (which everyone who edits outside of their comfort zone needs; and everyone who doesn't follow their local community extremely closesly needs), there is finally a simple, structured source including all the different kinds of channels that are used. Of course we can hope people find this yet-another-website. But I would think that connecting mappers to other mappers is just as important as connecting them to the right tags. In the end, it is these other mappers who define what the correct tags are anyway.
Apart from OSM messages and GeoChat, are there any other communication channels I'm not aware of within JOSM? These two aren't as directly helpfull in finding local groups, but maybe I'm missing something else?
That's not a task for the core.