On the list page have link to tags

[barnaclebarnes]

On this page there should be a link to the current tag processing for each layer:

http://linz2osm.openstreetmap.org.nz/data_dict/dataset/mainland/

The page should have the comments for the layer and also the javascript that has been added for each tag.

This will mean that anyone can view the state of the tagging without having a login and should make people more comfortable with what we are doing. It also allows people to feedback on the mailing list with suggestions without them having to be admins on the tool.

[HamishB]

awesome. could you sort it to have global tags last, and any non-global LINZ: tags second to last? (put the interesting-to-osm stuff first)

also, should we show any non-default ReverseWay or CW winding processing lower down on that tagging-preview page?

Hamish B

[HamishB]

on the tagging preview page, http://linz2osm.openstreetmap.org.nz/data_dict/layer/mast_pnt/tagging/

I wonder if we could have some sort of magic where it would grey-out boxes where there are no features attached to that fields.* in any data set?

for example in the above mast_use1 and mast_use2 have been removed in the latest dataset and are no longer relevant. (until linz changes their mind again and brings it back in the next version...)

also, if a rule was broken (e.g. the tagger used field.* instead of fields.*) maybe the box could come back with an obnoxiously red background?

Hamish

[stephend]

awesome. could you sort it to have global tags last, and any non-global LINZ: tags second to last? (put the interesting-to-osm stuff first)

I'll have a look and see.

also, should we show any non-default ReverseWay or CW winding processing lower down on that tagging-preview page?

Oh yeah, whoops. I meant to do that...

[stephend]

I wonder if we could have some sort of magic where it would grey-out boxes where there are no features attached to that fields.* in any data set?

I had a look at that. It's possible, but I think it's a bit too much work for a fairly minor feature.

for example in the above mast_use1 and mast_use2 have been removed in the latest dataset and are no longer relevant. (until linz changes their mind again and brings it back in the next version...)

also, if a rule was broken (e.g. the tagger used field.* instead of fields.*) maybe the box could come back with an obnoxiously red background?

There's no bottom to that rabbit hole, so I'm not going to start. I think the preview is going to be a better way to test the tagging.

[stephend]

Whoops, meant to include processing also.

[HamishB]

There's no bottom to that rabbit hole, so I'm not going to start. I think the preview is going to be a better way to test the tagging.

no end to it perhaps, but those are the two most common errors and the computer can do a better job spotting them than I can.

9 dumping all the rules to a text file would also help, then I could quickly grep for field.* (causes a server error on preview) and cases where the "*" part of that was longer than 10 chars (so likely places which hadn't been adapted to linz's new field names yet; fails silently, rare tags don't show up in the preview unless the preview is huge # of features). I've come across both of those errors in the tagging rules in the last 24 hours and digging through every single layer and hoping to spot them by eye is prone to human error and boredom in a way which computers aren't.

on the rainy-day wishlist, Hamish

[stephend]

On Wed, Aug 22, 2012 at 3:25 PM, HamishB notifications@github.com wrote:

There's no bottom to that rabbit hole, so I'm not going to start. I think the preview is going to be a better way to test the tagging.

no end to it perhaps, but those are the two most common errors and the computer can do a better job spotting them than I can.

9 https://github.com/opennewzealand/linz2osm/issues/9 dumping all the

rules to a text file would also help, then I could quickly grep for field. (causes a server error on preview) and cases where the "" part of that was longer than 10 chars (so likely places which hadn't been adapted to linz's new field names yet; fails silently, rare tags don't show up in the preview unless the preview is huge # of features). I've come across both of those errors in the tagging rules in the last 24 hours and digging through every single layer and hoping to spot them by eye is prone to human error and boredom in a way which computers aren't.

From the database, just the following four tags have the text 'field.':

tag | layer ------+--------------- name | canal_cl name | rapid_cl name | redoubt_pnt name | embankment_cl

I hope that helps a bit.

[stephend]

Rest of this is now #77

[HamishB]

From the database, just the following four tags have the text 'field.':

tag | layer ------+--------------- name | canal_cl name | rapid_cl name | redoubt_pnt name | embankment_cl

I hope that helps a bit.

thanks, all of those are now fixed. Is it possible to also make a list of javascript snippets (not osm tag names) containing more than 10 characters on the right hand side of "fields.*"? Not all of those will need to be fixed (in the case that LINZ has abandoned an otherwise useful-sounding one in this data version I'd just leave it as a no-op), but many of them will need to be updated.

Hamish

[stephend]

I have attached just such a list (LINZ:dataset is in there: the dataset_name and layer_name fields are added by linz2osm).

On Thu, Aug 23, 2012 at 7:57 PM, HamishB notifications@github.com wrote:

From the database, just the following four tags have the text 'field.':

tag | layer ------+--------------- name | canal_cl name | rapid_cl name | redoubt_pnt name | embankment_cl

I hope that helps a bit.

thanks, all of those are now fixed. Is it possible to also make a list of javascript snippets (not osm tag names) containing more than 10 characters on the right hand side of "fields.*"? Not all of those will need to be fixed (in the case that LINZ has abandoned an otherwise useful-sounding one in this data version I'd just leave it as a no-op), but many of them will need to be updated.

Hamish

— Reply to this email directly or view it on GitHubhttps://github.com/opennewzealand/linz2osm/issues/73#issuecomment-7962494.

           tag               |     layer_id     

---------------------------------+------------------ LINZ:airport_use | airport_pnt LINZ:bivouac_material | bivouac_pnt LINZ:symbol_orientation_radians | bivouac_pnt shelter_type | bivouac_pnt bridge | bridge_cl disused | bridge_cl highway | bridge_cl historic | bridge_cl LINZ:bridge_materials | bridge_cl LINZ:bridge_status | bridge_cl LINZ:bridge_use2 | bridge_cl man_made | bridge_cl railway | bridge_cl LINZ:symbol_orientation_radians | building_pnt LINZ:symbol_orientation_radians | building_poly LINZ:orientation_radians | cattlestop_pnt LINZ:fish_farm_type | fish_farm_poly LINZ:species_cultivated | fish_farm_poly LINZ:orientation_radians | ford_pnt access | gate_pnt LINZ:kiln_status | kiln_pnt LINZ:kiln_substance_extracted | kiln_pnt LINZ:temperature | lake_poly height | mast_pnt disused | mine_pnt LINZ:mine_status | mine_pnt man_made | mine_pnt mining_resource | mine_pnt disused | mine_poly LINZ:mine_status | mine_poly LINZ:mine_visibility | mine_poly mining_resource | mine_poly resource | mine_poly power | powerline_cl LINZ:orientation_radians | pylon_pnt disused | quarry_poly resource | quarry_poly LINZ:race_track_type | racetrack_poly sport | racetrack_poly LINZ:railway_track_type | railway_cl railway | railway_cl service | railway_cl construction | road_cl lanes | road_cl oneway | road_cl railway | rr_crossing_pnt leisure | sportsfield_poly LINZ:symbol_orientation_radians | stockyard_pnt ele | tower_pnt tower:construction | tower_pnt LINZ:trig_beacon_status | trig_pnt LINZ:dataset | (52 rows)