tags overview: showing "closed way" and "not closed way" numbers

[ImreSamu]

I have a problem, but I don't know what is the best solutions.

Analysing Nepal data, I have found some interesting tagging, for example: building=school tag used on "not closed way". Like: http://www.openstreetmap.org/way/219636845#map=19/27.64326/85.46386 ( version 1 )

And according to osm wiki, this tag "should not be used on ways" ( only nodes, areas, relations )

so my basic idea proposals:

• show "closed way"' and "not closed way" numbers at "overview" tab

improved idea:

• show alert message, when "not closed way" used with tags when this "should not be used on ways".

more improved idea:

• Creating taginfo reports like "Inconsistency in Tagging" - showing all inconsistent tag usage. ( including my example with Key:building + "not closed way" )

More info, maybe usefull, for analysing the problem and creating more universal solutions:

• Polygon/area def: Overpass turbo/Polygon Features and polygon json def
• Now the taginfo show "Number of closed ways:" and other interesing info for the full database ( reports:"Database statistics" )

This is not critical. Now I am using osm2pgsl and loading the data to PostgreSQL. and I can query this information with:

select * from planet_osm_line where building is not null;

one another idea:

• reusing osm2pgsq algorithm , and showing at the "overview tabs", how many tags are:
  • point ( loaded to osm2pgsql ->planet_osm_point )
  • line ( loaded to osm2pgsql ->planet_osm_line )
  • polygon ( loaded to osm2pgsql -> planet_osm_polygon )

[joto]

To proper differentiate between tags on ways and tags on areas, taginfo would have to implement multipolygon support. That is quite expensive to do so I have never added it. But yes, it would be nice to have at some point.

[ImreSamu]

thank you for your answer.

I understand that not so easy to balance between

• the global taginfo performance
• and the local taginfo requirements.

I am planning to test my idea myself, and create this report prototype, maybe with

• osm2pgsql or node-osmium
• and Taginfo Sqlite extract of wiki pages

And testing this report with hungarian taginfo instance

I have lot of other ideas :) waiting for test, and it would be usefull for me, if the next vesion of Taginfo implement a basic report add-on mechanism, like :

• Taginfo report add-ons ( to create new reports, for local or for HOT)
• Taginfo key-value TAB add-ons. ( to create new tabs ) [ in the future ]

I you are open this idea I will create a draft "Taginfo report add-ons" specification.

[joto]

Reports don't really fit all that well into taginfo and I have been unhappy with them for a long time. Unlike the rest of taginfo which tries to be very general, the reports are rather specialized. What types of reports there are was mainly driven by me having some idea some morning and quickly implementing it instead of any systemized thought process.

Instead of having more reports I think we should have less. Reports really should be created outside of taginfo. They can use the API and they can use the database downloads. This way they can be developed and run independently, use more datasource, use any database, any programming language they like. I understand the wish to "just add more reports" to taginfo, because it seems easiest. I have fallen for that many times myself.

Keeping the reports outside taginfo would also help make taginfo smaller and cleaner and easier to maintain. One way taginfo should develop is having a better split between API and user interface. At the moment it is all mashed together. And we'd probably need more, and better designed, API methods to support more diverse reports.

Of course one obvious drawback when putting the reports outside of taginfo would be the reduced integration. Some way of pointing to external reports would be nice, and, as you mention, some way of adding tabs would be nice, too. With the "Projects" support I have been trying to go into that direction, ie. integrate more outside data and tools with taginfo, so that taginfo doesn't have to do everything, but can stick to its main job and point to external services for more features. I could imagine, for instance, some way to add a tab with the content of the tab coming from an external web site.

All of these ideas are rather rough and I don't know yet how to realize them, but I think the way forward is not putting ever more things into taginfo, but to make it "play better" with other sites.

To go forward with this I think it would be good for you to think about what reports you want to have and what the minimal requirements are that you need from taginfo: What API and/or database downloads would you need for getting the data you want? What could a minimal/ideal user interface look like to integrate taginfo with the external report. Once we have a better idea of what we want, we can see whether we can solve this (mostly) outside taginfo or whether we need a tighter integration.

[jeisenbe]

I understand that showing the number of area features is quite computationally expensive, since it requires interpreting multipolygon relations.

But would it be possible to just show the numbers for closed ways vs unclosed ways?

Overpass API now supports searching for this, and it is quite helpful. See https://github.com/drolbr/Overpass-API/issues/419

It could be useful to show how many closed vs unclosed ways have a certain tag.