Back end prep for sub area topos

[brendanheywood]

This is a little while off yet, maybe 2 releases but just want to map out how it will work.

I'd like two back end process mods:

1) An add area process - basically exactly the same UI as adding a route, areas can be sorted etc. It could actually be the same UI and just a list of nodes. open to discussion

2) When saving data it will save three bits of shape data, routes, areas, and misc. misc will become all the other stuff like tracks that don't link anywhere inside the DB

[scd]

1. Except for the table names (TopoRoute & TopoRoutePaths) there is nothing in the tables which restricts to routes, so we can actually just use the existing table structure. Yah, but yuk for ongoing maintainence for the next developer who needs to realise that TopoRoute includes areas.

So yup, using the same UI gets my vote.

2a. From a database point of view the TopoRoutePoints can save any JSON data string. There may be some tinkering on the side to deal with validation, etc.

2b. If I'm understanding things correctly the misc fields will need a small change to the database structure. While the TopoRoute is not tied to a route, it is tied to a node, but misc is nodeless. The easy way around this is to make node optional and add a label field.

Does all this sound right to you?

[brendanheywood]

1) Ok lets go with same UI.

2a) do you just validate to JSON, or do you validate to the particular structure of the route points? The shape data for an area will be quite different, there will be:

{
  id:
  shape: [x,y,x,y,x,y ...], or similar
  style: 'visible' | 'hidden'  - some topos will look better if the shape is
                               hidden but clickable and just the label is visible
  label: {
    x:
    y:
    align: left | right | center
    valign: top | bottom | middle
    name:
  }
}

I'm also thinking about whether the label should always be just the name of the area node it's linked to or whether people can override it. Using existing guidebooks as test cases I think we need this

2b) Yes misc is nodeless. It will be json and you could validate it or you could just treat it like an opaque chunk of text.

[brendanheywood]

Ok two more things:

1) If we are using the same backend for routes and areas when you pass in the data I need to know wether I have a route or an area, so pass in type => 'route' | 'area'

2) I've always envisaged that a super topo could link to other topos, not just other areas. How easy would it be to use the same UI but also show the existing topos interleaved in the routes, same as list view, but with a checkbox etc. and then also pass in type => 'topo'.

[scd]

1) This should be easy 2) I don't think this fits in the current framework. Are you thinking of a topo in topo scenario or a topo adjacent to a topo. Like always I will try my best to make the system support your requirements. When you are ready please flesh this one out a bit more.

[brendanheywood]

• On big areas, with a super topo which shows all the other topos. Eg at redcliff in the original guide all the routes were 1 flat structure and I reorganised it to fit the topos, but not all cliffs are this easy. I'd prefer to fit the topo model to the index structure rather than restructuring crags to fit the topo model.
• similar to above with a crag like say KP. Each topo could overlap with the next one. We could have a region on either side of the topo, you click on it and you jump to the next topo.
• on large multi pitch like el cap have a topo of the whole route, and then little topos for each pitch.

At the end of the day, if we scrap this and stick with nodes only we probably get 80-90% or more of what guidebooks can do which is still pretty good

[scd]

We should support this. I'm going to show my understanding/lack of understanding with my following comments.

The model you described is a 'border' relationship between topos. There are a maximum of four borders (left,right,top,bottom) which will fully describe the real world you want to implement.

If this is the case then the implementation should be fairly straight forward.

1. Create left,right,top,bottom fields in the database
2. Extend the UI to allow linkages between topos based on one of the border types.
3. Extend templated data to include 'border' field.

[brendanheywood]

No I don't think hits the mark, a topo could contain other topos in any shape or place, the concept of left|right|up|down is way too simple and restrictive. I might want two topos that overlap on the top left corner and the bottom right corner. Or a sub topo right smack bang in the middle of another topo. Basically it should behave essentially exactly the same as linking to an area.

Consider this topo: http://icragguides.com/wp-content/uploads/2011/09/Overview2.jpg

Imagine you are at the 'Pharos gully' nodes topo, in the bottom right of the topo is the overlap of the adjacent topo but it's shape isn't the whole right side. In this case it links to a sibling node but it could just as easily link to another topo.

Or some of the more complex overlapping shapes in this one: http://www.osp.com.au/shop/images/large/arapiles-selected_01_LRG.jpg

I don't fully get how the backend data model works but I imagine it is something like this in OOP form

• Object
  • CIDS Object
  • Node
    • Area
    • Route
  • Topo

So basically at the moment a topo is linked via a table called TopoRoute to other routes, but in reality it should be called TopoNode. What I want is just to be able to link a topo to a list of CIDS Objects which could be a route, and area, or a topo. I can even see other types of object being link, like linking to an Account object from a topo like facebook does for photos.

From a template data perspective I'd want something like that passed in:

{
  {
    id: 12345,
    type: 'route',
    points: '   '
  },
  ...
  {
    id: 12345,
    type: 'area',
    shape: '  .... ',
    label: 'some area'
  }
  {
    id: 12345
    type: 'topo'
    shape: '  .... ',
    label: 'some topo'    
  }
}

From a UI perspective when you are in the topo edit process 'Add route(s)' would be renamed to 'Add routes or areas', when you go to that page you see a list of all the areas and topos for that area and can navigate around the index as usual, but if there are any topos attatched to the area then you also see those. They could be just jammed at the top but ideally they'd be interleaved with the routes in the same way as list view.

Stated in a completely different way, from the beginning topos we're always kinda subordinate to an area or route. Remember how originally the idea of more than one topo for an area seemed like an error? I kinda want to make topos first class citizens conceptually. You don't just get to topos from an area, you get to area's from a topo, or you get to topos from other topos.

I can see pretty clearly in my head exactly what I want but if you want I can do a few photoshop mockups.

[scd]

I just needed to get a shared vision and I understand now. When a person draws a box on a topo you want to link it too either another topo or an area.

Probably the easiest way around this is to de-type (ie remove the foreign key) the node reference in TopoRoutes table. This means I could store a reference to any entity in the database. Alternatively I could add an additional topo typed field and make both optional and just populate one of them.

The database namespace will be a bit screwy, but we can live with that while I am the main backend developer.

I will hold off doing this for a while, because more requirements may come in. But you can assume we will get some sort of implementation done to support in in the backend.

[brendanheywood]

Sweet. Sorry for the rant

On 18/05/2012, at 3:34 PM, scd reply@reply.github.com wrote:

I just needed to get a shared vision and I understand now. When a person draws a box on a topo you want to link it too either another topo or an area.

Probably the easiest way around this is to de-type (ie remove the foreign key) the node reference in TopoRoutes table. This means I could store a reference to any entity in the database. Alternatively I could add an additional topo typed field and make both optional and just populate one of them.

The database namespace will be a bit screwy, but we can live with that while I am the main backend developer.

I will hold off doing this for a while, because more requirements may come in. But you can assume we will get some sort of implementation done to support in in the backend.

---

Reply to this email directly or view it on GitHub: https://github.com/theCrag/website/issues/573#issuecomment-5780236

[scd]

I have detyped the topo route field so it can use any id. I have also made it optional in case we want to store idless stuff.

I need to work out what other fields should be added to the db record. So putting this all together, when the user presses the Save button, will you be passing to the server something like:

{ { id: route1_1, # system currently uses the css id which is mapped to a record id in the backend. If we wanted to change this to the actual record number or route number then this would probably be more robust type: 'route', # I need to add 'type' as a db record field. If it is omitted then I will assume it is a route points: '84 201 none,112 116 none,130 71 none,168 38 none,171 20 none' # actually there is no fundamental reason why you cannot use decimal points }, { id: area1_2, type: 'area', shape: '[x,y,x,y,....]', # whatever you define - the server will do no validation so it can be anything you define label: { # will be stored as serialised json in a new record field x: y: align: left | right | center valign: top | bottom | middle name: }, }, { id: topo1_3, type: 'topo', shape: '[x,y,x,y,....]', label: {
x: y: align: left | right | center valign: top | bottom | middle name: # ???? should we be storing a name for a topo label - I recon it should just be the area name. The label will just store the position for rendering the name. }, }

If this is what you are getting at I will need to create three additional db fields:

• type: text
• shape: serialised JSON
• label: serialised JSON

?????????

[brendanheywood]

I have made your life easy - What I have implemented so far is completely encoded everything into the points field, so the only thing I need extra is the 'type' field. The points data isn't a simple json string or anything so don't bother with any validation server side. If you are already doing server side validation then leave it there and I'll modify the encoding slightly so it will look just like the current route data.

There is actually a bunch more properties that a label will have, like width, a visibility toggle, a line toggle, and possibly more in the future so it's easier to just encode it all into one string that the DB isn't really aware of.

And yes it would be heaps simpler to use the node id as the id instead of what we currently do.

And also yes the topo will be storing the name, mostly because it may not be the same as the node name it points to. eg 'Hope buttress' could have a label saying 'Walk up valley to Hope Buttress' etc

...and also, did you guys in your wandering around Arap's take any zoomed out mega topo style pics that we could use as test cases for this? I'd like to hammer it with big messy test data as soon as I can.

I found this one which is a good start: http://www.thecrag.com/area/11764639

Any others good candidate photos?

And lastly, it's cool that we have the flexibility to add other topos, or any non node data. Will we get that in the first round? Will we also be able to link to the 'annotation' type?

[scd]

When you are ready let me know when you have swapped the front end code to be the actual node id and I should be able to swap it over. From the back end point of view, maybe it should be the id for the topo drawing object.

The DB has been detyped so non-node data should work from the backend perspective - although I will have to do a few code run throughs to make sure I'm not still doing some additional validation in the process code. There is a little bit of UI work getting the various entities on the list of things we can add to a topo. Unless I come across a non-trivial issue I will be doing this work for next release. While your heads in it, we might as well get as much done as possible.

What about some of the ACA photos?

[brendanheywood]

The topo currently reads and then writes using whatever Id it is, so there is no front end change? It would only make it more convenient to arbitrarily link to topos from elsewhere as you only need the id, and not the other unknown pseudo id.

The ACA ones' are not raw photos so not ideal as a fresh starting point. I'm more after a good quality panorama of the whole of araps, or of big chunks of it, like the central gully, or all of tiger wall and surrounds.

[brendanheywood]

I think we can close this?