J.D. Schmidt wrote: > Lester Caine skrev: >> >> Again - the fact that people are giving time to enter data is >> precisely why we need to be producing a guide to how to do things that >> is consistent. If people are going to tidy up these 'couple of >> problems' then we don't want one person deleting a node and another >> adding it back because they are looking at different views of the same >> data :( >> *ALSO* we also don't need people wasting time making the renderers >> play silly tricks to make things look right. Lets just be consistent >> in how things are handled. What ever the inconsistency! > > You need to look at it differently. From the view you are putting forth > above, you seem to equalize the rendered output in the form of Mapnik > and Osmarender maps to Openstreetmap. And I can see why, since those two > items produce the currently most visible part of OSM. > > BUT remember, the DB is one thing, the rendering of data from the db is > another thing altogether. Look at the db as a big sea of data, where it > is your (the rendering engine) task to harvest the data that you want to > render. Not to impose rules and limitations on what form the data in the > DB is entered in. > > IMHO one of the reasons why OSM has gained such "notoriety" and > following among neogeographers, established carthographers, and > joe-public alike, is the fact that it is not a mapproducing framework > bound by strict and defined ISO-like rules, but a framework that is more > akin to social networking for the map-inflicted. > > If the two rendering engines used currently differ in the way they > render said data, then its the rendering rules used in those engines > that need to be put into sync. Its not done by imposing limitations or > strict rules on what can/should be put into the DB.
THAT is all I am saying. EXCEPT that tagging should be consistent, something which does not happen currently. > If one person observed a parking lot, but didn't have time to log the > boundaries of the lot, and just placed a node with the corresponding > tag, then later another person comes along and logs the boundary of the > parking lot, and puts an area out of that data into the DB, he shouldn't > delete the node another person made. Maybe that person is using the data > from the DB to keep a POI record of parking lots. He might be the only > one doing so, but thats still one of the forces of the OSM project - Log > it, tag it, put it into the DB - even if you are the only person ever > going to use that data. We will have to differ there. Although I suspect that we are actually saying the same thing - just differently. There is a lot of tagging that is not rendered. That is fine, and while it would be nice to be consistent, deleting it is a matter of agreement. *IF* the tagging is being done properly, then both parking:area and parking:node should produce the same basic set of tags, so that upgrading a parking:node to a parking:area would retain all of the core information. If we are going to maintain two different sets of parking data nodes and areas then BOTH should be supplied. > So IMHO it's up to the rendering engines to render the data smartly. > It's not the rendering engines that decide what should be put into the DB. I see a major processing hit if every time you find an area you then have to process every node inside that area to see if it is ( whether parking, place or any other node/area conflict ) a duplicate of the area data. You then also have to decide if the node or area data takes priority? If one says private and the other public which should take priority. *I* am looking at the data here, and the problems I have with making the same decisions when two conflicting sets of tag information arises! -- Lester Caine - G8HFL ----------------------------- Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://home.lsces.co.uk MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/ Firebird - http://www.firebirdsql.org/index.php _______________________________________________ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
