Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Made OSM header accessible #24

Merged
merged 6 commits into from
Jun 22, 2017

Conversation

karsten42
Copy link
Contributor

As far as I could see there was no way so far to get hand on the OSM header information. It was only being decoded to check if the parser is capable of processing the file.
I added the possibility to get the header via the decoder which reads it from the file and stores it in the struct. The header will only be read one time from the file.

decode.go Outdated
@@ -15,6 +15,7 @@ import (

"github.com/golang/protobuf/proto"
"github.com/qedus/osmpbf/OSMPBF"
"sync"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

May you please move this import up?

decode.go Outdated
func (dec *Decoder) Header() (*Header, error) {
// synchronize with possible simultaneous call to 'Start()'
dec.mu.Lock()
defer dec.mu.Unlock()
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can sync.Once be a better choice here?

@jongillham
Copy link
Member

@karsten42 thanks for this! Have you thought about just having the Decode() return a *osmpbf.Header, just like it returns *osmpbf.Way etc instead of having a separate Header() function? I understand that only one *osmpbf.Header will be returned but to me if feels more natural with the way the API is right now. What do you think @AlekSi?

@karsten42
Copy link
Contributor Author

Yes, I thought about that.
But then there is now way of getting the header before you start going through the file, right?
In my application I actually get the header before reading the file to change some parameters.

@AlekSi
Copy link
Collaborator

AlekSi commented Jun 12, 2017

Decode reads the next object from the input stream and returns either a pointer to Node, Way or Relation struct representing the underlying OpenStreetMap PBF data, or error encountered.

I think it's too late to break public API after 1.0 even if the signature is not changed. A quick check of https://godoc.org/github.com/qedus/osmpbf?importers showed that people use switch over interface{} with default section, this will change a behavior.

@jongillham
Copy link
Member

@karsten42 and @AlekSi both good points! I concede.

@karsten42
Copy link
Contributor Author

@AlekSi I made your suggested changes. Good remark using sync.Once. I also fixed the tests I broke (shame on me).

@AlekSi AlekSi self-assigned this Jun 12, 2017
Copy link
Collaborator

@AlekSi AlekSi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are some minor issues, but I will fix them myself in the next PR. Thank you!

@AlekSi AlekSi requested a review from jongillham June 12, 2017 18:30
@AlekSi AlekSi assigned jongillham and unassigned AlekSi Jun 12, 2017
@AlekSi
Copy link
Collaborator

AlekSi commented Jun 12, 2017

@jongillham PTAL.

Copy link
Member

@jongillham jongillham left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice work. All my comments are suggestions that don't necessarily need to be addressed for the code to be merged.

decode.go Outdated
@@ -33,6 +34,24 @@ var (
}
)

type Bbox struct {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would this be better as BBox which better matches the osmformat.proto file of HeaderBBox or maybe even BoundingBox which is more descriptive?

Copy link
Member

@jongillham jongillham Jun 19, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I noticed the last commit 51ecde2 changed the name of Header.Bbox to Header.BoundingBox but it didn't include a change of type Bbox struct to type BoundingBox struct.

@@ -112,21 +136,24 @@ func (dec *Decoder) SetBufferSize(n int) {
dec.buf = bytes.NewBuffer(make([]byte, 0, n))
}

// Get the file header
func (dec *Decoder) Header() (*Header, error) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe this may be simplified to the following without any worries about race conditions:

func (dec *Decoder) Header() (*Header, error) {
    return dec.header, dec.readOSMHeader()
}

The dec.header pointer should always be passed to the calling function after dec.readOSMHeader() has been executed so dec.header will be set unless dec.readOSMHeader() produces an error. The down side of my suggestion is that the race condition, or lack thereof, is less explicit.

decode.go Outdated
// Get the file header
func (dec *Decoder) Header() (*Header, error) {
// deserialize the file header
err := dec.readOSMHeader()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could this be changed to the following in order to keep the err variable scope as small as possible?

if err := dec.readOSMHeader(); err != nil {
    return nil, err
}

decode.go Outdated
@@ -157,6 +184,8 @@ func (dec *Decoder) Start(n int) error {
// start reading OSMData
go func() {
var inputIndex int
var blobHeader *OSMPBF.BlobHeader
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there any advantage to putting blobHeader and blob outside the scope of the subsequent for loop? Would they be better declared implicitly at blobHeader, blob, err := dec.readFileBlock()?

@karsten42
Copy link
Contributor Author

@jongillham All very good remarks! I adapted the code accordingly.

decode.go Outdated
func (dec *Decoder) readOSMHeader() error {
var err error
dec.headerOnce.Do(func() {
blobHeader, blob, err := dec.readFileBlock()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe the err here will shadow the outer err making readOSMHeader() always return nil.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You are right, good catch.

Copy link
Member

@jongillham jongillham left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great work! I'm happy with this now. Are you able to squash it down to one commit and then we can merge it if I can't do it automatically with GitHub?

@jongillham jongillham merged commit b4b1bd9 into qedus:master Jun 22, 2017
HellButcher added a commit to HellButcher/osmpbf that referenced this pull request Jun 23, 2017
Make OSM header accessible (qedus#24).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants