amenity-recycling handling

[hybridOL]

The recycling POI has two very different kinds. One is recycling_type=centre meaning a larger area where certain kinds of recycling goods are dumped. Can be combined with some buildings and personnel at the centre, or just some place to dump e.g. green waste. The other one is a small container (recycling_type=container), where e.g. glass bottles or clothes are dumped. This is often not larger than 1x1x1m, so nothing compared to the centres.

Right now, the app does not distinguish between the two, which makes it rather disturbing to find hundreds of recycling centres across the city (as this is the current name shown in most if not all translations). Moreover, it does not help at all to find a recycling station of the proper type.

I guess it is not possible to print different names for the same amenity type. So we have to change the name of this amenity back from 'recycling centre' to 'recycling' and add details (recycling_type and materials, at least the most common ones, and at least for containers).

[hybridOL]

Another option would be to use the replaced_tags mechanism here as well. Not sure whether this works with editing the POIs then anymore, though. Especially for recycling containers, it would be really benefitial to have the opportunity to edit material types! Anyway, with renaming it could work this way: Remove amenity-recycling support and rename recycling_type=centre to mapsme-recycling_centre and same for _container. Then these would become to distinguishable objects.

[biodranik]

CC @Zverik

[shaforostoff]

a related issue is https://github.com/mapsme/omim/issues/8889

[biodranik]

@burivuh Who in the team handles OSM-related issues now?

[shaforostoff]

it would be good to see the type of recycling amenity: usually it is either glass, paper or plastic.

it is very handy if you travel and want to find a container to properly dispose your packaging

[Zverik]

It looks like there are two issues here:

1. We need to introduce amenity-recycling-centre with the translations currently used for the amenity-recycling.
2. Translations for the recycling should have "Recycling Container", "контейнер для переработки отходов" and so on. It would catch recycling_type=container and all other values, which are basically synonyms for that.

[shaforostoff]

3. also catch

• recycling:glass=yes
• recycling:glass_bottles=yes
• recycling:plastic=yes
• recycling:paper=yes

and add it to the text, for example "контейнер для переработки отходов (стекло)" or, in case there are several types: "контейнер для переработки отходов (стеклотара, пластик)"

also, you might prefer "контейнер для вторсырья" cause it is shorter

examples: https://www.openstreetmap.org/node/969075452 https://www.openstreetmap.org/node/2429457600

full list of types: https://wiki.openstreetmap.org/wiki/Tag:amenity=recycling

[Zverik]

3 — not for the mvp, because it's not a simple 1-line solution: one would need to add corresponding metadata fields, set up their editing, alter place cards for ios and android, add translations for "glass", "plastic" etc. That can be a full week job.

[biodranik]

@Zverik maybe you can create a short howto and mention all places in the code which should be updated for changes like that, so everyone in the world can try to do it?

[shaforostoff]

do I need to change any android code to implement that, or is it just a map generation code change?

i cloned omim master, but when I run configure.sh i get an error:

$ ./configure.sh ./configure.sh: 24: ./configure.sh: ./bootstrap.sh: not found

I run Debian testing.

P.S. I am a C++/Qt developer, and I would appreciate any help with implementing this feature, in English or Russian ;)

my skype id: shaforostoff fb: https://www.facebook.com/shaforostoff

[shaforostoff]

I have started adding recycling container types to maps generator: https://github.com/shaforostoff/omim/commit/17400539ac513796faf3c5f6c5b44317c32e0508

But now in the map that I generate, my 'reference' glass_bottles container has disappeared completely. Did I miss something? Could you help me, please?

[tatiana-yan]

@shaforostoff you should add data/styles and run tools/unix/generate_styles.sh. Styles tells the app how to display object. Generator drops objects without styles.

The easiest way to add styles is to copy it from some object.

[tatiana-yan]

You can see for example: https://github.com/mapsme/omim/pull/11338

There are 3 commits:

1. mapcss + editor (if you want to support adding this type with editor) + styles copied from natural=spring + strings + ugc (it does not work without ugc server).
2. generated styles (tools/unix/generate_styles.sh)
3. generated strings (tools.unix/generate_strings.sh)

[shaforostoff]

thanks. will try that. in the meantime, please review https://github.com/mapsme/omim/pull/13057 it will speed up compilation on linux and mac (do not forget to sudo apt-get install ccache on linux and brew install ccache on macOS to get the benefit of caching)

[shaforostoff]

I am curious to get your feedback: https://github.com/shaforostoff/omim/commit/2904cc34b27c5a8ab22d953948038fde220c85fa I tested it only with desktop MAPS.ME application: in my city I could see the objects of desired type

BTW, since one of the steps was generating binary files (drules_proto*.bin), did you consider making it a build/generation step?

[tatiana-yan]

Looks good now. Maybe it's better to separate autogenerated commits. We do not have resources mechanism for desktop app (it's "debug app" for developers, we are ok with that) so use see raw type in desktop, it's ok.

We do not want to convert autogeneration into build step because: 1) the main reason is: we need to review autogenerated files.

• human-readable drules.json are not used by app, it's just human-readable variant of binary drules. For complex style changes committer needs to check resulting change is right and reviewers need to check it to. Now committer generates resources, checks diffs and commits it. For autogeneration committer will need to generate from master, save current state, generate from branch, check diffs with saved state. Reviewers will need to checkout committer's branch and do the same. As person who commits/reviews resources from time to time I prefer current process.
  • we need to control symbols (icons) size because of old android devices support. Now we just review lines like this https://github.com/mapsme/omim/blob/d7691a1bd5d858fea67c58488802d970062b3399/data/resources-xhdpi_clear/symbols.sdf#L3 it's much easier to control when resources are commited 2) most of our developers newer touch types and strings so they do not need to setup twine/rbenv/kothic/python2.7, never deal with "ruby is broken after update to catalina" etc. As well as our maps generation servers and CI nodes. 3) resources generation takes time and mac os terminal is unusable at this time

[shaforostoff]

i have separated the changes into 3 commits: https://github.com/shaforostoff/omim/commits/recycling_types

https://github.com/mapsme/omim/pull/13113

[shaforostoff]

Here is another pull request: https://github.com/mapsme/omim/pull/13124/

It will assist implementing an approach similar to cuisines, with recycling types being a separate category.

This approach will require much more changes to the code, so I hope you will pick it up ;)

[tatiana-yan]

https://github.com/mapsme/omim/pull/13143